Failing Forward

In a current project of mine, I kept seeing random unhandled exceptions float up to the top of my application.  In cases where I suspect exceptions might be thrown, the code is smathered with some try/catch logic, per standard practice.  I also have a healthy stack of catch blocks wrapping the contents of main().  Theoretically, that shouldn’t ever get executed.

Theoretically.

Which means, it was a good thing it was there.

Without waxing the specifics of the problem, I was generally unable to trace the source of a particularly difficult to reproduce std::exception that kept bringing the application down.  Backed into a corner, I used the fail safe debugging method of the ages.  I cast a very wide try/catch net, and then slowly tightened it down the call stack of my 70-some file large C++ project.  Once I had pinned a sufficiently manageable block of code as the culprit, I had a brainwave.

I use GDB religiously (via Emacs) whenever I encounter any segmentation faults.  What used to take 15 minutes or more to track, now takes a whopping 30 seconds a worst.  One thing I’ve never done before, though, was to track exception logic with GDB.  Finding the information was trying, but eventually, some Googling led me to an Apple mailing list entry with the name of a very low level exception mechanism, called __cxa_throw().

Using GDB to sleuth the origin of any exception is easy with that function name.  Before you dive in, simply set a breakpoint for __cxa_throw.  GDB will halt and take you right to the source of any exception as soon as one is thrown.  Viola!  Now, tracking the source of any mysterious exception is as easy as locating seg faults.