Debugger - unhandled exception trapping?

Question

3.1.681
Can someone explain to me how to set up a Debugger trap for any unhandled exception?
I use Debug | Run | Exception Breakpoint (lit) | Unhandled Exception Throw (lit ) but it doesn't seem to save (When I come back it is unlit again)? Is there something more that needs to be done?
grin Is was fun looking at the documentation like "Step Over to Step Over the method" and then determining that "Step Over==Step" in other debuggers, and I can't find a "Step Over" ( or Skip ) function? sigh If each new town incorporated makes its own vocabulary, changing definitions while using the same words as another town.... well, I guess that's a really common issue in computer application tools.

Answer 1

You make me smile! Ok, the terms are confusing. I'm not going to lash anyone with a wet noodle, but hopefully the docs will get better, without any tortellini torture.
Ok, Step Over does execute the method without stopping (unless it encounters a real breakpoint somewhere). What you want is to NOT execute the method. Ok, we have such a feature (starting with JDev 3.1 I think), but it is only available with OJVM, which hopefully you are using! (Unless you specify -classic or -hotspot in the Java VM Parameters field of the Run/Debug tab in the project properties dialog box, then you are probably using OJVM).
Click in the editor and place the text cursor on the line that you want to skip to. Don't put the text cursor on the line you want to skip over, but do put it on the line where you want to end up. Then go to the main menu and choose Debug -> Set Next Statement. That will move the execution point of the current thread to the line where the text cursor is, without executing any code.
If the menu item is grayed, check the following:
1. You are using ojvm. You can verify this by looking in the message view while you are debugging. The message view shows the command which was used to start your program in debug mode. After the "...\jre\bin\java" part, there should be a -XXdebug. Note that there are two Xs. If -XXdebug is present, it means that you are using OJVM. If you see -classic or -hotspot or -Xdebug (only one X), then you are not using OJVM.
2. The text cursor in the code editor is on a valid and executable line of java code. Make sure it is not on a comment.
3. The text cursor is within the same method as the execution point. We don't let you "jump" into a different method.
Be very careful using this feature. We call it a buyer-beware feature. If you skip over initialization of local variables, you are likely to get into trouble very quickly, especially if the uninitialized variable is not a primitive type. If you skip over code which is "necessary" to the rest of you program, you are going to get into trouble.
You can also use this feature to repeat the execution of a statement. For example, if you pressed Step Over but you meant to Trace Into, you can put the cursor BACK on the line you wanted to trace into, do Set Next Statement, and then do Trace Into. Again, buyer-beware: if the code you are repeating causes side effects, then it may not be safe to repeat it.
About the exception breakpoint stuff. The problem arises from mixing old and new debugger architectures, which happened when we started supporting JDK 1.2 (new) and continued to support JDK 1.1 (old). The user interface was mostly written when we only supported JDK 1.1, and the UI basically matched the underlying debugging support. However, the debugging support we have in JDK 1.2 is a little different, so we try our best to match an old user interface to the new underlying debugging support.
Did you happen to go to Oracle Open World and check out JDev 5, which was shown at the "campground"? With JDev 5, we can all look forward to a better product, where the UI can be re-designed (where necessary) to better match the underlying capabilities.
Liz
null