Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-70148

Document proper noexcept usage

XMLWordPrintableJSON

    • Type: Icon: Task Task
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Service Arch
    • Service Arch 2023-08-21, Service Arch 2023-09-04, Service Arch 2023-09-18, Service Arch 2023-10-02, Service Arch 2023-10-16, Service Arch 2023-10-30, Service Arch 2023-11-13, Service Arch 2023-11-27, Service Arch 2023-12-11, Service Arch 2023-12-25, Service Arch 2024-01-08, Service Arch 2024-01-22, SP Prioritized List

      I think SERVER-50434 is a big deal.  This gcc bug means that when we violate a noexcept specification, we have very few tools for figuring out where it came from.  This happened in BF-26507 (an ongoing investigation) and in BF-17935.  We get no log messages saying what exception was thrown.  And in the case of BF-26507 (and possibly BF-17935), inlining makes the backtrace unhelpful.

       

      In most of the cases where we use noexcept for "exception handling," we would be better off catching the exception, logging a message, and calling std::terminate.

       

      I'm not sure how actionable this ticket is (feel free to close it as a duplicate of SERVER-50434), but I just want to bring people's attention to it.

       

            Assignee:
            backlog-server-servicearch [DO NOT USE] Backlog - Service Architecture
            Reporter:
            andrew.witten@mongodb.com Andrew Witten (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            12 Start watching this issue

              Created:
              Updated: