Where Do PrintStream Exceptions Go?

  • Thread starter Lawrence D'Oliveiro
  • Start date
L

Lawrence D'Oliveiro

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?
 
L

Lawrence D'Oliveiro

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?
 
J

javax.swing.JSnarker

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

Lew

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

javax.swing.JSnarker

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,013
Latest member
KatriceSwa

Latest Threads

Top