Feedback and comments on ARM proposal - resend

[Florian Weimer]

* Joshua Bloch:

> 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).