brainstorms

Thursday April 13, 2006

on unchecked claims on exceptions

recently came across various essays and rants [eg. here, here, here, ad nauseam] on java's checked exceptions. this was indirectly through tate's strange anti-java monograph. [more on that later] all in all, mildly intriguing.

fluff: some of the authors use phrases and words like conventional wisdom, myth, orthodoxy, and refer to well-regarded experts for support, which must impress many. evidently computing is now a field in which the power of a passionate "expert" essay more often than not trumps the necessity and power of empirical content that one can objectively put to test.

historic details: happily for CS literacy, one of the commentators on bruce eckel's essay, kevlin henney, did identify CLU as well as modula-3 as precursors to java in exceptions, and mentions a good [but probably mostly unread] overview: a history of CLU. [kevlin also points to modula-3 report as a reference, but alas that report does not discuss the rationale behind the design of its exception mechanism. i am tempted to email luca cardelli and ask...] CLU history paper has an interesting section on the design of CLU exceptions. to quote: [emphasis mine]

CLU’s mechanism is unusual in its treatment of unhandled exceptions. Most mechanisms pass these through: if the caller does not handle an exception raised by a called procedure, the exception is propagated to its caller, and so on. We rejected this approach because it did not fit our ideas about modular program construction. We wanted to be able to call a procedure knowing just its specification, not its implementation. However, if exceptions are propagated automatically, a procedure may raise an exception not described in its specification.

CLU wanted the cake and eat it too:

Although we did not want to propagate exceptions automatically, we also did not want to require that the calling procedure handle all exceptions raised by the called procedure, since often these represented situations in which there was nothing the caller could do. For example, it would be a nuisance to have to provide handlers for exceptions that ought not to occur, such as a bounds exception for an array access when you have just checked that the index is legal. Therefore, we decided to turn all unhandled exceptions into a special exception called "failure" and propagate it. This mechanism seems to work well in practice.

[alas, so far as I am aware, CLU practice was limited to university teaching, not large-scale industrial use.]

liskov also quotes an earlier sharp observation:

The hardest part of designing an exception handling mechanism, once the basic principles are worked out, is to provide good human engineering for catching exceptions.

nicely put.

obref: Bergin and Gibson, history of programming languages, addison-wesley, 1996. [it includes the liskov history paper, as well as a transcript of her presentation and the question and answer session that followed.]

[i would like to visit this topic again soon, and see if we can do something about empirical content...]