Feedback and comments on ARM proposal (original) (raw)

Florian Weimer fw at deneb.enyo.de
Wed Mar 18 14:58:11 PDT 2009

I don't think it's realistic, ever, to change this because it isn't compatible to take a throws clause off of an overridable method: it breaks subtypes. One of the things that adds to the pain is the silliness of IOException itself. Why are all exceptions raised during IO checked? No good reason:(

It reminds me of Haskell. 8-)

IOException is used very inconsistently. System.out.println() should certainly throw it, and there quite a few methods in File which should, too (basically, anything that hits the file system).

On the other hand, the current state of affairs means that it's not possible to use the new-style for loop to iterate over all the lines in a file, which is somewhat annoying.

Why, in fact, is there such a thing as an IOException? That only tells you where the exception comes from, which you can find out by looking at its class and package. Given the need for a hierarchy, it's a waste to use an exception's sole ancestor to duplicate this information. Much better is to group exceptions based on what they indicate rather than where they come from.

I guess the only way to handle an IOException is to determine where it comes from, dynamically. The concrete cause isn't that important. For instance, if a piece of code deals with data from the network and some on-disk structure, you probably can recover locally from a network outage, but a disk write error is something that requires operator attention. Of course, with Java's IOException, you still need to wrap the I/O operations to get this distinction. But if the IOException class had some sort of associated I/O resources, a single-routed hierarchy would make some sense, I think.

Anyway, I've worked with systems which lacked hierarchical exceptions, and it's not really that great, either. It's basically impossible to handle most errors locally (which is true for I/O disk errors, but not for many forms of network errors).

More information about the coin-dev mailing list