Next up in the series on the debugger is the addition of conditional breakpoints. In case you missed the first in the debugging series, see my post on
Viewing variables during a TUI converse. I also linked to
What's new in IBM Rational Business Developer version 8 article that you should definitely check it out if you haven't already. The What's new article covers the basics of using conditional breakpoints so I won't repeat it here. If you are familiar with Eclipse (and even if you aren't), setting conditional breakpoints is easy. Simply specify the condition under which the breakpoint should suspend the program's execution. Once the condition is met and the suspend occurs, you can inspect variables and their values and step through the program.
I want to share some notes and cautions on conditional breakpoints:
- Conditional breakpoints are powerful but you need to use them with care. Since an expression is being compiled and run on the fly, they're going to affect applicationperformance. The more conditional breakpoints, the bigger the performance hit. Global conditions are especially useful, but they're also being evaluated at every statement of every program, so having several of them enabled can cause your application to slow down quite a bit. Personally I only enable them when I need to debug a specific issue. No need to delete them - just disable them and they won't be evaluated.
- Conditional breakpoints can invoke pretty much any code - including functions. This means the code executed during the breakpoint's evaluation can change the values of fields, run a commit on a database, call a remote program, etc...so please be careful with the code that gets executed!
- The conditions are evaluated in the current context of the application. For line breakpoints (i.e. non-global breakpoints), errors in the evaluation will cause an error dialog letting you know about the error. For example, the condition array.getSize() > 0 can throw a NullValueException if array is null. You will also get an error dialog if the conditional expression could not compile, or it did not resolve to a Boolean expression. You have two options when an error occurs: edit the condition, in which case it will be re-evaluated after you finish editing it, or suspend at the breakpoint.
- Related to the previous note, you will never be prompted with error dialogs for global conditions. This is because your global condition might only be valid in certain parts of the application. The expression foo > 10 is only going to be valid in places that have a variable named foo, and we found that displaying error dialogs when foo didn't exist was a huge hindrance - every line causing an error dialog.
And now I have a few questions for you....
Question 1: Do you think we should display an error dialog for errors that occur while running the evaluation, and only ignore errors about not being able to compile the expression? Or do you think that would still be annoying with the potential for many error dialog popups, and it should remain as it is? Make it an option that can be toggled?
Question 2: Global conditions are disabled once triggered, otherwise they would typically cause the application to suspend on every line. e.g. once condition "x == 5" becomes true, it will stay true until "x" is no longer 5, or "x" is no longer in scope. Would you find it useful to be able to set a property on a global conditional breakpoint that prevents it from automatically disabling?
Post a comment to this blog and let us know what you think!
Justin