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

Reinier Zwitserloot reinier at zwitserloot.com
Wed Mar 18 17:16:14 PDT 2009

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

More information about the coin-dev mailing list