Don't Nail Your Program into the Upright Position
m (Don't nail your program into the upright position moved to Don't Nail Your Program into the Upright Position)
I once wrote a spoof C++ quiz, in which I satirically suggested the following strategy for exception handling:
- By dint of plentiful
try...catchconstructs throughout our code base, we are sometimes able to prevent our applications from aborting. We think of the resultant 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 suffered the pokings of many programmers' fingers over the years: nobody's hands were clean. It contained code to deal with all escaped exceptions from everything 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.
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 EXCEPTION 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 towards the door.
By Verity Stob
This work is licensed under a Creative Commons Attribution 3
Back to 97 Things Every Programmer Should Know home page