Feedback and comments on ARM proposal - resend

[Reinier Zwitserloot]

Obviously, in response to a failed close() on an OutputStream, you'd  
do the same thing you usually do on a failed write():

You consider the entire writing of the file, from start to finish, as  
a failed endeavour. You then pop up a dialog box to the user to  
explain why the file save operation failed, for example, or you return  
a certain HTTP error, or you actively ignore the exception because  
you're just writing some cache info for the next instance.


If at any time you are dependent on a -specific- write() call's  
exceptions, you should ALWAYS call flush() in between.


Is there anyone else other than Howard who considers AutoClosable NOT  
throwing any exceptions a good idea? If not, I think we can move on.

  --Reinier Zwitserloot



On Mar 18, 2009, at 23:26, Howard Lovatt wrote:

> 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
>> ______________________________________________________________________
>>