Re: Where Do PrintStream Exceptions Go?
On Mar 27, 11:27 pm, "javax.swing.JSnarker" <gharri...@boojum.mit.edu>
wrote:
On 27/03/2011 11:20 PM, Lawrence D'Oliveiro wrote:
In message<imou82$56...@lust.ihug.co.nz>, Lawrence D'Oliveiro wrote:
Write to most OutputStreams, and you have to deal with the possibility=
of
IOExceptions. But wrap an OutputStream in a PrintStream, and the
IOExceptions magically go away.
So what happens to those IOExceptions?
OK, found checkError/setError.
Next question: why two different error-reporting mechanisms?
Probably so that System.out.println debugs can be sprinkled through your
codebase without having to tack "throws IOException" on just about
everything, or else wrap the printlns in try/catch.
Just one more wart in the language related to the notion of "checked
exceptions".
And your justification for calling it a "wart" in the "notion of
'checked Exceptions'" is what, exactly?
This is not in any way the fault of the notion of checked exceptions;
rather it shows an advantage of the notion.
It is a design decision not to use a certain checked exception.
Checked exceptions live at the behest of the API writer. That the
writer gets to choose is the design purpose. That designer chose not
to use it. So you are calling one of its signal advantages a "wart".
I bet if PrintStream didn't eat the exceptions you'd be out there
complaining why they didn't make the obvious decision to eat them,
since the language gives that power and the debugging use case calls
for that.
Some people will bitch about the strengths of a system, but logic is
against them.
--
Lew
--
Lew