-
Type:
Task
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Server Programmability
-
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, Programmability 2024-12-09
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.
- is related to
-
SERVER-50434 exceptions violating noexcept can be invisible to terminate handler
-
- Backlog
-
- related to
-
-
- Needs Scheduling
-