Where Do PrintStream Exceptions Go?

Discussion in 'Java' started by Lawrence D'Oliveiro, Mar 28, 2011.

  1. 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?
    Lawrence D'Oliveiro, Mar 28, 2011
    #1
    1. Advertising

  2. In message <imou82$56s$>, 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?
    Lawrence D'Oliveiro, Mar 28, 2011
    #2
    1. Advertising

  3. On 27/03/2011 11:20 PM, Lawrence D'Oliveiro wrote:
    > In message<imou82$56s$>, 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.
    javax.swing.JSnarker, Mar 28, 2011
    #3
  4. Lawrence D'Oliveiro

    Lew Guest

    On Mar 27, 11:27 pm, "javax.swing.JSnarker" <>
    wrote:
    > On 27/03/2011 11:20 PM, Lawrence D'Oliveiro wrote:
    >
    > > In message<imou82$>, 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
    Lew, Mar 28, 2011
    #4
  5. On 28/03/2011 1:34 PM, Lew wrote:
    > On Mar 27, 11:27 pm, "javax.swing.JSnarker"<>
    > wrote:
    >> On 27/03/2011 11:20 PM, Lawrence D'Oliveiro wrote:
    >>
    >>> In message<imou82$>, 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.
    javax.swing.JSnarker, Mar 28, 2011
    #5
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Novice
    Replies:
    1
    Views:
    1,124
    Mike Schilling
    Jul 19, 2003
  2. Harald Hein

    Re: PrintStream to Writer

    Harald Hein, Aug 20, 2003, in forum: Java
    Replies:
    2
    Views:
    5,357
    karl wettin
    Aug 20, 2003
  3. Ahmed Moustafa
    Replies:
    5
    Views:
    29,983
    Chris Smith
    Jul 14, 2004
  4. www
    Replies:
    1
    Views:
    1,464
  5. Evol
    Replies:
    5
    Views:
    375
Loading...

Share This Page