Verity Stob
i ONCE WROTE A SPOOF C++ qUiz, in which I satirically suggested the fol- lowing strategy for exception handling:
By dint of plentiful try…catch constructs throughout our codebase, we are sometimes able to prevent our applications from aborting. We think of the resul- tant state as “nailing the corpse in the upright position.”
Despite my levity, I was actually summarizing a lesson I received at the knee of Dame Bitter Experience herself.
It was a base application class in our own, homemade C++ library. It had suf- fered the pokings of many programmers’ fingers over the years: nobody’s hands were clean. It contained code to deal with all escaped exceptions from every- thing else. Taking our lead from Yossarian in Catch-22, we decided, or rather felt (decided implies more thought than went into the construction of this monster) that an instance of this class should live forever or die in the attempt.
To this end, we intertwined multiple exception handlers. We mixed in Windows’ structured exception handling with the native kind (remember __try…__except in C++? Me, neither). When things threw unexpectedly, we tried calling them again, pressing the parameters harder. Looking back, I like to think that when writing an inner try…catch handler within the catch clause of another, some sort of awareness crept over me that I might have accidentally taken a slip road from the motorway of good practice into the aromatic but insalubrious lane of lunacy. However, this is probably retrospective wisdom.
56 97 Things Every Programmer Should Know

Needless to say, whenever something went wrong in applications based on this class, they vanished like Mafia victims at the dockside, leaving behind no useful trail of bubbles to indicate what the hell happened, notwithstanding the dump routines that were supposedly called to record the disaster. Eventually—a long eventually—we took stock of what we had done, and experienced shame. We replaced the whole mess with a minimal and robust reporting mechanism. But this was many crashes down the line.
I wouldn’t bother you with this—for surely nobody else could ever be as stupid as we were—but for an online argument I had recently with a bloke whose academic job title declared he should know better. We were discussing Java code in a remote transaction. If the code failed, he argued, it should catch and block the exception in situ. (“And then do what with it?” I asked. “Cook it for supper?”)
He quoted the UI designers’ rule: NEVER LET THE USER SEE AN EXCEP- TION REPORT, rather as though this settled the matter, what with it being in caps and everything. I wonder if he was responsible for the code in one of those blue-screened ATMs whose photos decorate the feebler blogs, and had been permanently traumatized.
Anyway, if you should meet him, nod and smile and take no notice, as you sidle toward the door.