This is a planned, or at least previously discussed, follow-up to SERVER-98918.

SERVER-98918 installed a customizable throw hook behavior into the server. We can execute a function when a throw happens.

The problem is that throws happen all the time and they're a benign part of proper error handling and don't indicate that logging or stack tracing is necessary. Doing any of that would be an over-reaction and spam our logs.

As an initial mitigation, we attempted to filter the logging so that we only report on exceptions OTHER than DBException, because we were interested in the origin of a certain standard library exception as part of a targeted investigation.

Soon afterward, we saw that this is producing alarms in correct code that's working as designed.

SERVER-100564 log noise in the shell
AF-1965 log noise while probing the OS for tcp options

We must not set up a situation where we have to avoid making calls that might throw execptions, just because they'll spam the logs. If I call vector.at(i), which might be out of range but probably isn't, and catch it at a higher call frame layer, that's perfectly valid exception-leveraging style. To do otherwise is a pessimization.

The proposal is to use the throw hook to capture a minimal address-only trace when an exception is thrown, and stash it in a shadow mapping associated with that exception via some mechanism TBD. If and only if that exception becomes a problem (like causing a std::terminate or other unexpected condition) we will have richer metadata about its origin that we can retrieve and dump to a log.

One idea was developed hypothetically in a comment here.
https://jira.mongodb.org/browse/AF-1965?focusedCommentId=7281212&focusedId=7281212&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-7281212