C++ Exceptions: Under the Hood (2013)

Working with and implementing C++ exceptions for 30 years now, including implementing exception handling for Windows, DOS extenders, and Posix (all very different), and then re-implementing them for D, I have sadly come to the conclusion that exceptions are a giant mistake.<p>1. they are very hard to understand all the way down<p>2. they are largely undocumented in how they&#x27;re implemented<p>3. they are slow when thrown<p>4. they are slow when not thrown<p>5. it is hard to write exception-safe code<p>6. very few understand how to write exception-safe code<p>7. there is no such thing as zero-cost exception handling<p>8. optimizers just give up trying to do flow analysis in try-exception blocks<p>9. consider double-fault exceptions - there&#x27;s something that shows how rotten it is<p>10. has anyone yet found a legitimate use for throwing an `int`?<p>I have quit using exceptions in my own code, making everything &#x27;nothrow&#x27;. I regret propagating exception handling into D. Constructors that may throw are an abomination. Destructors that throw are even worse.

Author here; worth noting this article was written a decade ago, and while the concepts it describes are probably still useful (or so I&#x27;m told) the text is starting to show its age. Most notably, the examples are completely broken for x86-64, as I didn&#x27;t have a 64bit processor when writing this.

&gt; When the personality function doesn&#x27;t know what to do it will invoke the default exception handler, meaning that in most cases throwing from a nothrow method will end up calling std::terminate.<p>This is an interesting tidbit that cost me a week of debugging recently - a try&#x2F;catch block at the top of the call stack wasn&#x27;t catching an exception.<p>We set up an exception handler that calls main in a try&#x2F;catch block, so that any thrown exceptions can be caught, processed, and dispatched to our crash-logging system.<p>But destructors are marked nothrow by default. So we had a case where an object was destroyed, and about 10 levels down from its destructor some other system threw an exception, intending it to be caught by the top-level catch block.<p>But during stack unwinding we passed through the nothrow destructor and std::terminate got called before unwinding got to the top-level try&#x2F;catch.

Implementation in Windows is quite different. Especially x86 vs x86-64 which has much less overhead. Also gets quite complicated with the Windows built-in Structured Exceptions&#x2F; asynchronous exceptions which can be translated into c++ exceptions -- and even more complexity due to different compiler options that handle these!

[2013]ish if I remember.<p>Also note the ABI for C++ exceptions followed by G++ et al is actually documented as part of the Itanium C++ ABI :<p><a href="https:&#x2F;&#x2F;itanium-cxx-abi.github.io&#x2F;cxx-abi&#x2F;abi-eh.html" rel="nofollow">https:&#x2F;&#x2F;itanium-cxx-abi.github.io&#x2F;cxx-abi&#x2F;abi-eh.html</a>

Under the hood of GCC specifically.

Very interesting read, however it is under the hood on a specific implementation.

Just dropping by to say hi to a fellow c++ing monkey