Feedback and comments on ARM proposal - resend

[Howard Lovatt]

In my suggestion of not using checked exceptions for dispose I am not
proposing retrofitting to an existing interface, I am proposing
retrofitting a new interface to an existing class or wrapping an
existing class in a new class that implements the new interface. I was
deliberately suggesting that trying to deal with the current IO with
all its vagourasies as amply highlighted by Josh, Reinier, and Florian
is an impossible task. Hence the suggestion not to try. In particular
I am suggesting:

    interface AutoResource { void autoDispose(); }

When you fit AutoResource to an existing class or to a new class you
have to make the modified/new class conform to the contract of
AutoResource, which is that the resource is auto opened, autoDispose
can be called multiple times, and autoDispose is called by the system
for you. I am not saying that autoDispose can't throw an unchecked
exception; just that it is inappropriate to throw a checked exception
because the user of the resource can do little to recover from the
problem of a closure error, so there is no point in burdening the
programmer with a checked exception.

In the example of a buffered write that does no writes until close is
called and hence a write error is reported on close, what can the user
do? The only way for the user to deal with the close exception would
be to keep track of all the writes that they used so that when close
fails they can be retried (like some transactional databases do).
Actually it is even harder than this, you have to know which writes
succeed and which failed! I can't see people wanting to do this for
every print statement and alike; also it is more the functionality of
some underlying framework, rather than the core language.

  - Howard.

2009/3/19 Florian Weimer <fw at deneb.enyo.de>:
> * 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).
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>