Exception handling features in languages are fantastic. They let us (if we're careful and thorough) express the mainline logic of our code uninterrupted by the niggly little detail that just about anything can fail at just about any time, and then let us handle those failures in clearly-defined "...and if that goes wrong, do this" blocks. In pseudocode:
Lovely and wonderful. We were able to express what we're really trying to do (this, that, and the other) clearly, but then handle the fact that this, that, or the other can fail. The equivalent in, say, C would be to use the convention that returning 0 means everything was fine and returning !0 means something went wrong:
catch (ExceptionalCondition ec)
// Handle it
(Although you probably wouldn't write it quite like that.)
if (doThis() == 0)
if (doThat() == 0)
if (doTheOther() == 0)
// Handle the fact that something failed
So for obvious reasons I'm a big fan of exception constructs, but there's a refinement I've been wanting for a good 10+ years now (maybe it's about time I got around to submitting a JSR or something; they don't seem to be getting my telepathic messages):
This is probably best expressed with an example:
As you can see, the goal here is to separate the logic that handles errors reading from the socket from the completely unrelated logic that handles errors writing to the file.
// Not shown: Opening the input and output, allocating the buffer,
// getting the socket's input stream
while (/* ... */)
count = input.read(buffer, 0, buffer.length);
output.write(buffer, 0, count);
catch (IOException ioe from input)
// Handle the error reading the socket
catch (IOException ioe from output)
// Handle the error writing to the file
A very basic idea, but I've never heard of anyone implementing it. This may be because I'm so shockingly brilliant that no one else has ever thought of this. (A kind reader will not immediately consider the converse argument.) Or, more likely, there are a lot of subtleties involved that make it tricky.
For instance, exceptions thrown by other objects being used under-the-covers by the socket or file output stream instance need to be handled as though thrown by the socket or output stream instance once they get to the level where we've caught them. But that shouldn't be that hard, although it would require that the stack trace record instance information.
Another wrinkle comes from checked exceptions: Does my code above throw IOException, or not? I've caught it if it's thrown by
output, and those are the only two instances I've used methods on that may throw the exception, so no, my code doesn't throw
IOException. But it'll require enhancing compilers so they can figure that out. But that, too, doesn't seem that complicated.
It's very hard to do the above (in a general way) without language support, hence the suggestion that it may be worth adding a construct to the language.