Don't Nail Your Program into the Upright Position

From WikiContent

(Difference between revisions)
Jump to: navigation, search
Current revision (16:14, 3 July 2009) (edit) (undo)
 
(5 intermediate revisions not shown.)
Line 1: Line 1:
I once wrote a spoof C++ quiz, in which I satirically suggested the following strategy for exception handling:
I once wrote a spoof C++ quiz, in which I satirically suggested the following strategy for exception handling:
-
: By dint of plentiful ''try...catch'' constructs 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'.
+
: By dint of plentiful <code>try...catch</code> constructs 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 summarising a lesson I received at the knee of Dame Bitter Experience herself.
+
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.
+
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.
+
To this end, we intertwined multiple exception handlers; we mixed in Windows' structured exception handling with the native kind (remember <code>__try...__except</code> 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 <code>try...catch</code> handler within the <code>catch</code> 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 &mdash; a long eventually &mdash; we got took stock of what we had done, and experienced shame, and replaced the whole mess with a minimal and robust reporting mechanism. But this was many crashes down the line.
+
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 &mdash; a long eventually &mdash; 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 &mdash; for surely nobody else could ever be as stupid as we were &mdash; 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?')
+
I wouldn't bother you with this &mdash; for surely nobody else could ever be as stupid as we were &mdash; 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 traumatised.
+
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.
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
 +
[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
 +
 +
 +
 +
Back to [[97 Things Every Programmer Should Know]] home page

Current revision

I once wrote a spoof C++ quiz, in which I satirically suggested the following strategy for exception handling:

By dint of plentiful try...catch constructs 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

Personal tools