0

I have code such as below:

@Override
    protected Void doInBackground() throws Exception {
        try {
            while(true) cpu.step();
        } catch(Throwable t) {
            throw new RuntimeException(t);
        } finally {
            System.out.println("EmulationWorked task completed");
        }
    }

This loop should always exit by throwing an exception, but in my case I see that the control reaches the println statement without doing so.

My Java/JVM version is as below:

java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)

This question is related to an issue I was seeing as part of another issue I posted previously: Gameboy emulation - SwingWorker stuck at Unsafe.park

Is this a known JVM bug of some kind?

Community
  • 1
  • 1
rationalrevolt
  • 663
  • 1
  • 6
  • 13
  • 2
    Please read what `finally` does. – Sotirios Delimanolis Oct 21 '13 at 03:56
  • The method should complete by always throwing an exception, which does not happen in my particular case. I know that the finally block will always execute. – rationalrevolt Oct 21 '13 at 03:57
  • How do you know it's not happening in this particular case? – musical_coder Oct 21 '13 at 03:59
  • Because, if I put a breakpoint at the catch block (which catches all Throwable) - it doesn't break. But, a breakpoint at the statement on the finally block does break. – rationalrevolt Oct 21 '13 at 04:01
  • Finally will always be executed regardless if you throw an exception or not. That's what it's for. – Radiodef Oct 21 '13 at 04:02
  • What happens when you put a `print` statement at the beginning of the `catch` block? Does it appear in addition to the print statement in `finally`? – musical_coder Oct 21 '13 at 04:03
  • I apologize, I was mistaken. The breakpoint did break on the catch block. I will close this question. I guess the since this exception happened in a background SwingWorker thread, it was never reported on the console. – rationalrevolt Oct 21 '13 at 04:04
  • 1
    Also note that catching all throwables and wrapping in a runtime exception is redundant as SwingWorker will already do that. Any exceptions that are thrown in doInBackground() are automatically wrapped in an ExecutionException and can be caught by calling get() in done(). – Radiodef Oct 21 '13 at 04:04

1 Answers1

0

I was mistaken. The breakpoint did break on the catch block. Since this exception happened in a background SwingWorker thread, and I was not interested in the final result (not calling get in the done method) the exception was swallowed by Swing.

rationalrevolt
  • 663
  • 1
  • 6
  • 13