0

I got this from Java™ I/O, 2nd Edition By Elliotte Rusty Harold :-

it would be inconvenient to wrap a try/catch block around each call to System.out.println( ), Sun decided to have PrintStream (and later PrintWriter) catch and eat any exceptions thrown inside a print( ) or println( ) method. If you do want to check for exceptions inside a print( ) or println( ) method, you can call checkError( ):

public boolean checkError( )

The checkError( ) method returns TRue if an exception has occurred on this print stream, false if one hasn't. It tells you only that an error occurred. It does not tell you what sort of error occurred. If you need to know more about the error, you'll have to use a different output stream or writer class.

I just wana test this checkError method for true return type....

Any clues for creating some practical scenarios for this... :-)

mogli
  • 1,549
  • 4
  • 29
  • 57

1 Answers1

4

Here's a couple of scenarios where checkError() will return true:

Scenario #1

  1. Open an output stream for a file to a small filesystem/device; e.g. a floppy disc?
  2. Create a PrintStream
  3. Loop for ever writing to the PrintStream.

Eventually the filesystem will fill up and writes will fail.

Scenario #2

  1. Open a URL connection to some HTTP server.
  2. Get the OutputStream for the connection
  3. Create a PrintStream
  4. Write some output to the PrintStream.
  5. Call getStatus() on the connection, or call closeConnection
  6. Try to write some more output.

Writes should now fail because the HTTP connection is no longer in the right state for sending data to the remote server.

These scenarios are practical, in the sense that you should be able to make them give you errors. But they are not entirely realistic. For example, you wouldn't normally use a PrintStream to send POST data to an HTTP server. But that's the root of the differences in the OutputStream versus PrintStream APIs. The OutputStream / Writer APIs are designed for use-cases where the application needs to know if output fails. The PrintStream / PrintWriter APIs are designed for "light-weight" use-cases such as outputting user messages to the console where handling failure is ... umm ... a waste of programmer effort.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • I have tried both the scenarios u suggested, and in both the cases checkError() is returning true (Cheers :)). But this last line (from the original post) is not getting clear to me. "If you need to know more about the error, you'll have to use a different output stream or writer class." – mogli Oct 23 '09 at 06:13
  • 1
    What he is saying is that the Print* APIs do not provide any way to get hold of the Exception(s) that caused the printer object to go into the error state. – Stephen C Oct 23 '09 at 06:29
  • your suggested scenarios pop up a new question. Both in, out are declared public static final in System class, then how it is possible to call setters for these. final are supposed to be initiallized only once??? – mogli Oct 23 '09 at 06:39
  • 1
    Look at `System.setIn()` and friends. – Stephen C Oct 23 '09 at 07:16