from Hacker News

C++ Exceptions: Under the Hood (2013)

by arcatek on 8/12/21, 9:17 PM with 111 comments

• by WalterBright on 8/13/21, 1:32 AM

  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.

  1. they are very hard to understand all the way down

  2. they are largely undocumented in how they're implemented

  3. they are slow when thrown

  4. they are slow when not thrown

  5. it is hard to write exception-safe code

  6. very few understand how to write exception-safe code

  7. there is no such thing as zero-cost exception handling

  8. optimizers just give up trying to do flow analysis in try-exception blocks

  9. consider double-fault exceptions - there's something that shows how rotten it is

  10. has anyone yet found a legitimate use for throwing an `int`?

  I have quit using exceptions in my own code, making everything 'nothrow'. I regret propagating exception handling into D. Constructors that may throw are an abomination. Destructors that throw are even worse.

• by nicolasbrailo on 8/13/21, 8:32 AM

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

• by cecilpl2 on 8/13/21, 3:13 AM

  > When the personality function doesn'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.

  This is an interesting tidbit that cost me a week of debugging recently - a try/catch block at the top of the call stack wasn't catching an exception.

  We set up an exception handler that calls main in a try/catch block, so that any thrown exceptions can be caught, processed, and dispatched to our crash-logging system.

  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.

  But during stack unwinding we passed through the nothrow destructor and std::terminate got called before unwinding got to the top-level try/catch.

• by adzm on 8/13/21, 1:15 AM

  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/ asynchronous exceptions which can be translated into c++ exceptions -- and even more complexity due to different compiler options that handle these!

• by AshamedCaptain on 8/12/21, 9:56 PM

  [2013]ish if I remember.

  Also note the ABI for C++ exceptions followed by G++ et al is actually documented as part of the Itanium C++ ABI :

  https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html

• by zabzonk on 8/12/21, 10:14 PM

  Under the hood of GCC specifically.

• by pjmlp on 8/13/21, 6:53 AM

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

• by monkeycantype on 8/13/21, 1:06 AM

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