0

I have the following piece of code:

void func()
{
  try
  {
    f1()
  }
  finally()
  {
     if (resource != null)
       resource.close();
  }
}

I put three breakpoints: call to f1(), inside f1(), on the if statement in the finally block.

It appears that the breakpoint in finally block is not being hit. If after hitting the breakpoint inside f1() I step using the next command, I indeed end up going through the finally block.

Also If I put breakpoints on both the lines of the finally block, the breakpoint is indeed hit for the first one.

Not sure if this is due to a bug in JDB. Can someone tell me if this is a known issue or if I am missing something?

I am using JDK 6 on Linux.

Rohit Banga
  • 18,458
  • 31
  • 113
  • 191
  • You need to post a more complete example. This is too short, obviously artificial, and buggy. – g051051 Jul 30 '11 at 03:01
  • I saw this bug while executing proprietary code. I doubt if I will be able to reproduce it with a standalone example. – Rohit Banga Jul 30 '11 at 03:24

1 Answers1

5

I don't quite understand what unexpected behavior you're seeing, but JDB has no problem debugging if's, finally's, or if's inside of finally's. If you're seeing apparent breakpoints being skipped, then most likely you're looking at source code that differs from the bytecode that's running. It's possible to check the line numbers in the bytecode by disassembling it with

javap -c -l <simple class name>

in the same directory as the class file. It can also be run as

javap -c -l -classpath <build dir> <fully qualified class name>

It will show all of the instructions that each method contains with a numeric label. There will be a "LineNumberTable" that associates those labels to source code line numbers. Note: there are usually many bytecode instructions per source code line.

Ryan Stewart
  • 126,015
  • 21
  • 180
  • 199