Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Where Do PrintStream Exceptions Go?

Reply
Thread Tools

Where Do PrintStream Exceptions Go?

 
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      03-28-2011
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?
 
Reply With Quote
 
 
 
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      03-28-2011
In message <imou82$56s$(E-Mail Removed)>, 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?
 
Reply With Quote
 
 
 
 
javax.swing.JSnarker
Guest
Posts: n/a
 
      03-28-2011
On 27/03/2011 11:20 PM, Lawrence D'Oliveiro wrote:
> In message<imou82$56s$(E-Mail Removed)>, 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.
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      03-28-2011
On Mar 27, 11:27*pm, "javax.swing.JSnarker" <(E-Mail Removed)>
wrote:
> On 27/03/2011 11:20 PM, Lawrence D'Oliveiro wrote:
>
> > In message<imou82$(E-Mail Removed)>, Lawrence D'Oliveiro wrote:

>
> >> Write to most OutputStreams, and you have to deal with the possibilityof
> >> 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
 
Reply With Quote
 
javax.swing.JSnarker
Guest
Posts: n/a
 
      03-28-2011
On 28/03/2011 1:34 PM, Lew wrote:
> On Mar 27, 11:27 pm, "javax.swing.JSnarker"<(E-Mail Removed) u>
> wrote:
>> On 27/03/2011 11:20 PM, Lawrence D'Oliveiro wrote:
>>
>>> In message<imou82$(E-Mail Removed)>, 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
why System.out is wrapped with PrintStream but System.in not? Evol Java 5 09-03-2009 03:56 AM
a Java io question -- disable line buffering of PrintStream www Java 1 01-30-2007 06:53 PM
Checked exceptions vs unchecked exceptions Ahmed Moustafa Java 5 07-14-2004 01:46 PM
Re: PrintStream to Writer Harald Hein Java 2 08-20-2003 09:02 PM
java.io.BufferedWriter and java.io.PrintStream - a seeming parameter/argument mismatch in method invocation Novice Java 1 07-19-2003 06:46 PM



Advertisments