Feedback and comments on ARM proposal - resend

[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:(  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.
    Josh

On Wed, Mar 18, 2009 at 1:45 PM, Florian Weimer <fw at deneb.enyo.de> wrote:

> * Reinier Zwitserloot:
>
> > The general feeling that close() throwing IOExceptions is just plain
> > stupid comes from *INPUTSTREAM*, where your inputstream reading has
> > not thrown any exceptions, and has therefore, by neccessity, read all
> > files and hit the EOF (or whatever other 'I don't need more data'
> > marker you're using) without error.
>
> This requires quite a few library changes because currently, an
> InputStream created for a ReadableByteChannel which happens to be a
> WritableByteChannel as well closes both personae of the channel when
> the input stream's close method is invoked.  You'd have to change
> that, or you still end up encountering exceptions during close.
>
>