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?

In message <imou82$56s$1@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?

On 27/03/2011 11:20 PM, Lawrence D'Oliveiro wrote:
> In message<imou82$56s$1@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".

-- 
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides 
snarky output when the Ego.needsPuncturing() event is fired in cljp.

On Mar 27, 11:27=A0pm, "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

On 28/03/2011 1:34 PM, Lew wrote:
> 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?

The fact that having two completely different kinds of error handling in 
just a few I/O classes constitutes a wart, of course.

That it's the truth is the only justification I need for making such a 
statement.

> This is not in any way the fault of the notion of checked exceptions;
> rather it shows an advantage of the notion.

Causing warts to proliferate through library designs is an "advantage"? 
Well, maybe to career language lawyers it is. Job security. ;)

> 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".

It would have been nicer (and still inconsistent with other I/O error 
handling) to throw an unchecked PrintStreamException type instead of 
silently record errors somewhere.

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

Nope; see above. Better would have been an unchecked exception. Better 
still would have been *no checked exceptions*, or a warning rather than 
an error for an unhandled, undeclared checked exception, with maybe an 
@SuppressWarnings option available for the case that it's not temporary 
debug code but it can never actually throw the exception (e.g. 
MalformedURLException declared as being thrown by the URL constructor, 
but the code at issue uses a string literal to create the URL; if it 
*does* throw, due to a typo in that literal, that's a bug right there 
and not an invalid input from the outside world and so the exception 
going unhandled and blowing things up with a stack trace is exactly the 
right behavior anyway).

> Some people will bitch about the strengths of a system, but logic is
> against them.

So, it is your expressed belief that if anything constitutes "a strength 
of a system" in *your opinion*, then that automatically, and in and of 
itself, makes that thing *infallible*?

Wow.

-- 
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides 
snarky output when the Ego.needsPuncturing() event is fired in cljp.