views:

1220

answers:

9

I have a thread in which I catch all errors in a big, all-encompassing catch block. I do this so that I can report any error, not just expected ones, in my application. My Runnable looks like this:

public final void run()
{
    try
    {
        System.out.println("Do things"); /* [1] */

        doUnsafeThings();
    }
    catch (Throwable t)
    {
        System.out.println("Catch"); /* [2] */

        recover();
    }
    finally
    {
        System.out.println("Finally"); /* [3] */
    }
}

I would expect the NPE to be caught by the Throwable catch block. Instead, the output at [2] is not printed, and neither is [3]. The output at [1] is printed.

What I do get on the console, is this:

Uncaught exception java/lang/NullPointerException.

What on earth is going on here?

For the court records, I'm using J2ME, and this is running in Sun's WTK v2.5.2 emulator.

I'm tempted to put it down to JVM implementation dodginess but I can't help feeling that I'm just missing something.

To clarify for the avoidance of doubt (Since the example code is obviously altered from my production code)

  • There is nothing outside of the try/catch/finally block in the run method.
  • There is a System.out.println at the start of each of those blocks - What follows those console statements should not matter.
A: 

Is it possible that the thread is being killed by some other code? In general a finally block always executes unless the thread is abnormally terminated, either by System.exit() or something similar.

Mr. Shiny and New
Unfortunately this is not possible. The system does not exit, and the code is built for CLDC 1.0 (Basically a subset of the Java API), which means that there is no way to terminate a thread. It's not part of the API - threads only exit when run() exits.
izb
Can you verify that your thread is actually exiting? Is it possible the thread is still alive, but blocked due to an exception somewhere, and only appears to have died from the outside?
Mr. Shiny and New
+3  A: 

Okay, this is a wild guess... but it would explain things.

Obviously your code isn't actually that - so my guess is that your catch (or finally) block is either doing something before it logs anything, or it uses a different logger than the try block. Either way, I suspect that either the catch or the finally block is throwing the exception.

I don't suppose you have a stack trace...

EDIT: Okay, if it's just System.out.println, is it something in the argument that might go bang? For example:

catch (Throwable t) {
    // Will go bang if t.getCause() returns null
    System.out.println(t.getCause().getMessage());
}

If it's just simple System.out.println("Constant") then it's very weird.

Do you know (e.g. from log lines within the try block) how far the try block is actually getting?

Jon Skeet
No stack trace, no (Can't catch it). And my update to my question just now addresses some of your answer. There's no logging framework involved either.. just System.out.println.
izb
A: 

What exactly happens in doUnsafeThings()?
Is System.out being set to null?

Carlos Heuberger
+3  A: 

Sounds like you'll need some trial and error. May I suggest:

try {
    doEvilStuff();
} catch (NullPointerException ex) { 
    System.out.println("NPE encountered in body"); 
} catch (Throwable ex) {
    System.out.println("Regular Throwable: " + ex.getMessage());
} finally {
    etc...
}

By having an explicit catch for NullPointerException, it should become obvious if the exception is from within the try block or a catch/finally block.

Mike
+1  A: 

When I looked at your code it seems that recover() is throwing an exception, so the advice given by Jon would be excellent to follow.

If you gave us a stack trace you may get better help.

When I try to catch exceptions I do something like this:

try {
  doSomethingBad();
} catch(Exception e) {
   try {
      LogException(...);
   } catch(Exception e) {}       
} finally {
}

I don't like to nest exceptions, but I don't like my catch block throwing exceptions.

James Black
A: 
  • Are you sure you are looking at the right place in the code? I.e., is the doUnsafeThings() block you are protecting in of the stack trace?

  • Maybe there is a problem with your build method, and you are debugging an old version of the code?

mfx
A: 

just add some logging in the doUnsafeThings(); to see if that method is doing what you expect (e.g put a try catch finally and log something)

silmx
+1  A: 

As you mention you are using a Runnable - does this by any chance mean that you are using multiple threads as well? If the doUnsafeThings() method internally spawns a different thread again and that produces the exception, you might not get it in the thread your catch block is. See http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.UncaughtExceptionHandler.html

Daniel Schneller
+1  A: 

I'm closing this question because the answer turns out that I'm an idiot. I'd explain what went wrong, but let's just call it "one of those bugs".

izb
Please let us know :)
Paul Whelan
Inquiring minds want to know. We've all done boneheaded things.
Adam Jaskiewicz
I had momentarily forgotten that the thread that ran the runnable was a custom thread class (To get round some Nokia bugs). It called run() repeatedly between calls to a 'canWait()' method. The canWait method was responsible for the failure, and run wasn't failing at all. To top it off, I have console-blindness and completely but accidentally misquoted the sequence of events in my question.
izb
+1 and my thanks for following up with the answer!
Adam Liss