Feedback and comments on ARM proposal - resend
reinier at zwitserloot.com
Wed Mar 18 12:03:15 PDT 2009
the IOException that spins off of file writes is obviously a clear cut
case of appropriate use of a checked exception. The point is simply
that 'close' on an *OUTPUTSTREAM* makes a lot of sense. Lots of
outputstreams use buffering, and in theory your .close() call is the
first one that will make anything filter from java through to the OS,
and would thus be the first time you get an IOException. In other
words, a close() call on an OutputStream can result in write() calls
on an underlying non-buffered outputstream, which implies that
removing IOException off of an OutputStream's close() method makes
absolutely no sense whatsoever unless you also remove it from
OutputStream's write() methods. If you're willing to do that, either
you're arguing in favour of removing checked exceptions altogether, or
otherwise you ought to be arguing that IOException should be re-homed
to RuntimeException. Neither of which is on the table for coin.
Because ARM should obviously handle OutputStream, it is therefore
impossible, within the scope of project coin, to sensibly make ARM
Closables not throw anything on close() methods.
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. In practice, InputStream.close()
throws an IOException about as often as new String(someBytes,
"UTF-8"); throws an UnsupportedEncodingException (i.e.: you'll win
the lottery first, and get hit by lightning a few times, before
that'll ever happen). Therefore, removing IOException from InputStream
(and Reader)'s close() methods makes sense, but wouldn't be backwards
compatible, so isn't on the table for coin.
On Mar 18, 2009, at 05:50, Howard Lovatt wrote:
> Hi All,
> 2009/3/15 Neal Gafter <neal at gafter.com>:
>> Agreed, though there is one context in which it is possible to jump
>> into the scope of a local variable declaration without "executing"
>> declaration: the switch statement.
> I thought this was only in C/C++ and Java had plugged this hole - I
> guess I am wrong - do you have an example.
More information about the coin-dev