Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Dealing with checked exceptions in your <code>run()</code> method is tricky for the following reasons:</p> <ol> <li><p>As @kenson john says (and you observed) you can't simply let them propagate, because <code>run()</code> is not declared as throwing checked exceptions.</p></li> <li><p>If you catch them and rethrow them wrapped in unchecked exceptions, they are likely to go unnoticed by the <code>main</code> thread. Why? Because the exceptions are thrown on the stack of the child thread. Unless they are caught in the <code>run()</code> method, they will be dealt with by the thread's <a href="http://download.oracle.com/javase/6/docs/api/java/lang/Thread.UncaughtExceptionHandler.html" rel="nofollow"><code>UncaughtExceptionHandler</code></a> object ... which is likely to be the default handler ... which writes a stacktrace to <code>System.err</code> and then discards the exception.</p></li> <li><p>Now you can set another <code>UncaughtExceptionHandler</code> object for the child thread, or even set a default <code>UncaughtExceptionHandler</code> for the JVM. But what should the handler do? Ideally, the exception needs to be reported back to the <code>main</code> thread (or whatever) to take executive action. But there's no way that the child thread, or a handler for that thread can throw an exception on the main thread's stack. (The best you could do to get the main thread's attention would be to set a flag or call <code>Thread.interrupt()</code> on the main thread ... and hope that it checks the flag / interrupt status periodically.)</p></li> <li><p>Any <code>IOException</code> that is thrown while writing to an output file indicates that something serious has gone wrong; e.g. the file system is full, or the socket or pipe you were writing to is broken / closed. So simply ignoring it <strong>could be</strong> a big mistake. (For instance, suppose that the file is precious, and that the last thing that the application does is to delete the old version of the file and replace it with the new version we just created. Ooops! We didn't notice that the FS filled up, the new version of the file is corrupt and we just deleted the old version.)</p></li> </ol> <p>In the light of this, the <code>PrintStream</code> approach is simplest. A <code>PrintStream</code> will quietly catch any <code>IOException</code> that occurs while writing, but record the fact that an exception has occurred. So when the <code>main</code> thread decides that everything should have finished writing, it needs to call <a href="http://download.oracle.com/javase/6/docs/api/java/io/PrintStream.html#checkError%28%29" rel="nofollow"><code>PrintStream.checkError()</code></a> to test if any errors have occurred. (Unfortunately, the API does not allow you to find out what the actual exception was.)</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload