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:
http://neversaw.us/2010/9/8/javascript-and-nodejs-gotchas/
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 :)
Cheers,
Antranig.
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
