I could have sworn that I wrote this up before, but apparently I’ve never posted it, even though it’s been one of my favorite rants for years.
In my “What’s wrong with this code, Part 6” post, several of the commenters indicated that I should be using structured exception handling to prevent the function from crashing. I couldn’t disagree more. In my opinion, SEH, if used for this purpose takes simple, reproducible and easy to diagnose failures and turns them into hard-to-debug subtle corruptions.
By the way, I’m far from being alone on this. Joel Spolsky has a rather famous piece “Joel on Exceptions” where he describes his take on exception (C++ exceptions). Raymond has also written about exception handling (on CLR exceptions).
Structured exception handling is in many ways far worse than C++ exceptions. There are multiple ways that structured exception handling can truly mess up an application. I’ve already mentioned the guard page exception issue. But the problem goes further than that. Consider what happens if you’re using SEH to ensure that your application doesn’t crash. What happens when you have a double free? If you don’t wrap the function in SEH, then it’s highly likely that your application will crash in the heap manager. If, on the other hand, you’ve wrapped your functions with try/except, then the crash will be handled. But the problem is that the exception caused the heap code to blow past the release of the heap critical section – the thread that raised the exception still holds the heap critical section. The next attempt to allocate memory on another thread will deadlock your application, and you have no way of knowing what caused it.
The example above is NOT hypothetical. I once spent several days trying to track down a hang in Exchange that was caused by exactly this problem – Because a component in the store didn’t want to crash the store, they installed a high level exception handler. That handler caught the exception in the heap code, and swallowed it. And the next time we came in to do an allocation, we hung. In this case, the offending thread had exited, so the heap critical section was marked as being owned by a thread that no longer existed.
Structured exception handling also has performance implications. Structured exceptions are considered “asynchronous” by the compiler – any instruction might cause an exception. As a result of this, the compiler can’t perform flow analysis in code protected by SEH. So the compiler disables many of its optimizations in routines protected by try/catch (or try/finally). This does not happen with C++ exceptions, by the way, since C++ exceptions are “synchronous” – the compiler knows if a method can throw (or rather, the compiler can know if an exception will not throw).
One other issue with SEH was discussed by Dave LeBlanc in Writing Secure Code, and reposted in this article on the web. SEH can be used as a vector for security bugs – don’t assume that because you wrapped your function in SEH that your code will not suffer from security holes. Googling for “structured exception handling security hole” leads to some interesting hits.
The bottom line is that once you’ve caught an exception, you can make NO assumptions about the state of your process. Your exception handler really should just pop up a fatal error and terminate the process, because you have no idea what’s been corrupted during the execution of the code.
At this point, people start screaming: “But wait! My application runs 3rd party code whose quality I don’t control. How can I ensure 5 9’s reliability if the 3rd party code can crash?” Well, the simple answer is to run that untrusted code out-of-proc. That way, if the 3rd party code does crash, it doesn’t kill YOUR process. If the 3rd party code is processing a request crashes, then the individual request fails, but at least your service didn’t go down in the process. Remember – if you catch the exception, you can’t guarantee ANYTHING about the state of your application – it might take days for your application to crash, thus giving you a false sense of robustness, but…
PS: To make things clear: I’m not completely opposed to structured exception handling. Structured exception handling has its uses, and it CAN be used effectively. For example, all NT system calls (as opposed to Win32 APIs) capture their arguments in a try/except handler. This is to guarantee that the version of the arguments to the system call that is referenced in the kernel is always valid – there’s no way for an application to free the memory on another thread, for example.
RPC also uses exceptions to differentiate between RPC initiated errors and function return calls – the exception is essentially used as a back-channel to provide additional error information that could not be provided by the remoted function.
Historically (I don’t know if they do this currently) the NT file-systems have also used structured exception handling extensively. Every function in the file-systems is protected by a try/finally wrapper, and errors are propagated by throwing exception this way if any code DOES throw an exception, every routine in the call stack has an opportunity to clean up its critical sections and release allocated resources. And IMHO, this is the ONLY way to use SEH effectively – if you want to catch exceptions, you need to ensure that every function in your call stack also uses try/finally to guarantee that cleanup occurs.
Also, to make it COMPLETELY clear. This post is a criticism of using C/C++ structured exception handling as a way of adding robustness to applications. It is NOT intended as a criticism of exception handling in general. In particular, the exception handling primitives in the CLR are quite nice, and mitigate most (if not all) of the architectural criticisms that I’ve mentioned above – exceptions in the CLR are synchronous (so code wrapped in try/catch/finally can be optimized), the CLR synchronization primitives build exception unwinding into the semantics of the exception handler (so critical sections can’t dangle, and memory can’t be leaked), etc. I do have the same issues with using exceptions as a mechanism for error propagation as Raymond and Joel do, but that’s unrelated to the affirmative harm that SEH can cause if misused.