Don't Nail Your Program into the Upright Position - Revision history

Kevlin: Don't nail your program into the upright position moved to Don't Nail Your Program into the Upright Position

Kevlin — Fri, 03 Jul 2009 16:14:06 GMT

Don't nail your program into the upright position moved to Don't Nail Your Program into the Upright Position

←Older revision

Revision as of 16:14, 3 July 2009

Kevlin at 16:13, 3 July 2009

Kevlin — Fri, 03 Jul 2009 16:13:18 GMT

←Older revision		Revision as of 16:13, 3 July 2009
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 <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'.	+	: 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 summarizing 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 <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.	+	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 — 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.		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?")	+	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.		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.

Kevlin at 15:50, 22 November 2008

Kevlin — Sat, 22 Nov 2008 15:50:18 GMT

←Older revision		Revision as of 15:50, 22 November 2008
Line 9:		Line 9:
	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.		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 — a long eventually — we 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 — 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?')	+	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.		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.

Verity.stob: Americanizing the spelling

Verity.stob — Tue, 18 Nov 2008 22:03:37 GMT

Americanizing the spelling

←Older revision		Revision as of 22:03, 18 November 2008
Line 3:		Line 3:
	: 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'.		: 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.
Line 13:		Line 13:
	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?')		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 ~~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.

Verity.stob at 21:48, 18 November 2008

Verity.stob — Tue, 18 Nov 2008 21:48:26 GMT

←Older revision		Revision as of 21:48, 18 November 2008
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 summarising a lesson I received at the knee of Dame Bitter Experience herself.
Line 7:		Line 7:
	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 — a long eventually — we 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 — a long eventually — we 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.
Line 16:		Line 16:

	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

Verity.stob at 10:14, 18 November 2008

Verity.stob — Tue, 18 Nov 2008 10:14:02 GMT

←Older revision		Revision as of 10:14, 18 November 2008
Line 9:		Line 9:
	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 ''__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 ~~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 — a long eventually — we 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.

	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?')		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?')

Verity.stob at 10:02, 18 November 2008

Verity.stob — Tue, 18 Nov 2008 10:02:02 GMT

←Older revision		Revision as of 10:02, 18 November 2008
Line 9:		Line 9:
	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 ''__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 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 — a long eventually — 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.

	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?')		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?')

Verity.stob at 09:59, 18 November 2008

Verity.stob — Tue, 18 Nov 2008 09:59:50 GMT

←Older revision		Revision as of 09:59, 18 November 2008
Line 11:		Line 11:
	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 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 -- a long eventually - 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.

-	I wouldn't bother you with this — for surely nobody else could ever be as stupid as we were — but for an online 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 — 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 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 traumatised.

	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.

Verity.stob at 09:58, 18 November 2008

Verity.stob — Tue, 18 Nov 2008 09:58:09 GMT

←Older revision		Revision as of 09:58, 18 November 2008
Line 5:		Line 5:
	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 summarising 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~~ 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 ''__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 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 -- a long eventually - 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.

-	I wouldn't bother you with this -- for surely nobody else could ever be as stupid as we were -- but for an online 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 — for surely nobody else could ever be as stupid as we were — but for an online 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 traumatised.

	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.

Verity.stob: First attemps

Verity.stob — Tue, 18 Nov 2008 08:42:49 GMT

First attemps

New page

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 summarising 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 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 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.

I wouldn't bother you with this -- for surely nobody else could ever be as stupid as we were -- but for an online 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.

Anyway, if you should meet him, nod and smile and take no notice, as you sidle towards the door.