The End of Exceptions

Antranig Basman antranig.basman at
Sat Jun 4 07:09:31 UTC 2011

Confirming a chat with Colin that I had after my posting a few weeks ago about the unusability of exceptions 
in browser JavaScript, I came across this posting which reports another angle of the this issue, which is 
the serious devaluation which exceptions face in event-driven programming:

I can't say I agree with the first two points of the author's 5-point summary, but halfway down the article 
is a useful commentary on "Where does that error go?". This points out that in heavily callback-driven 
programming, try-catch blocks are largely worthless anyway since they can very rarely in practice succeed in 
bracketing the source of the error. To relay some of the discussion with Colin, this established that under 
the model that exceptions are reserved for "truly exceptional conditions", these could only ever arise from 
an interaction with the outside world - which implies that some form of I/O has taken place. And since under 
the node.js as well as browser model, all I/O is asynchronous, the site of the actual I/O could never be 
bracketed with try/catch. This leaves the only remaining role for exceptions as *assertions* representing an 
error by the developer. In this restricted case, destroying the current stack and displaying a reasonably 
intelligible error trace is the right disposition.

"Events are the new exceptions" - I found this confirmed when dealing with getting Kettle working once more 
in node.js and found that the up-to-date version of jsdom which we are using to provide a thin simulation of 
a browser environment for getting jQuery to boot up insists on reporting all script loading errors with an 
"onerror" event on the "document", rather than by throwing an exception. Any attempt to rethrow an exception 
simply leads to an infinite recursion as this is converted back into an "onerror" event :)


More information about the fluid-work mailing list