Exception Catching Policy

In an ideal world, Microsoft would have adhered to the C++ standard, and made catch(...) not catch system exceptions like 'Access Violation', however this is not the case.

To make it worse, not only do system exceptions get caught by catch(...), they also bypass the stack unwinding. This is quite problematic in an environment where this mechanism is relied upon for resource management, commonly 'only' memory, but also including multithreading acces control mechanisms.

One of the big problems with Access Violations is that it is an unplanned exception, and in many situations will leave data structures incomplete, resources locked or other equally vicious artifacts. Essentially, it breaks invariants. One viable take on this is that if you don't know where an exception came from, you shouldn't be catching it.

A big advantage of letting access violations and it's ilk (or any other unplanned exception) through is that these will then get caught by the JIT (Just In Time) handlers such as Dr. Watson and Compiler environments that allow immediate or post-mortem debugging of the problem. A lot of projects (like Mozilla) have their own bug-reporting which can intercept the bugs at the top level and generate their own crash dumps, and catching these exceptions is actually going to bypass a very useful mechanism.

All this is to say that we have made a shift away from exception handling policies that cause system expeptions to be caught, however in order to allow as much flexibility as possible, an improved exception handling mechanism has been added to the interface implementations and to the server implementation that uses catch and rethrow to allow logging and custom handling of all exceptions.

The default action of the mechanisms will be to finally rethrow unknown exceptions. The good thing about this is that the rethrow behaves to a JIT handler as if the expeption had never been caught.