Dynamic Breaks based on object state

Hi,

I have been looking to see of the Debugging of Java Programing could be made much more valuable  in the following context

1. When the application is lacks of lines
2. The debugging team is different than the orginal developer
3. Same string or value may exist for an object in more than one place
4. The string or object value is not static but dynamic

an e.g for this is

When one would like to know the line where object status results in xyz. In the case of string of resulting string  "Error 108 - File Currupted Error of file name: c:\temp\input.txt" then break point should happen with the exact line where such string is resulted. In a program such string may be done mostly "Error " +erroNo+ "- File Currupted Error of file name: "  + fileName etc.

In all such cases, dynamic breaks defination which is delcarable based on object status can give many insites and helps the debugger to know the starting line more easily.

Would be happy to know if the forum thinks the same and if there is already such feature.. if yes, pl. point me to right way or approach to accemplish this.


Regards,
Raja Nagendra Kumar,
C.T.O
www.tejasoft.com

2 comments
Comment actions Permalink

You can set a field watch point. See Procedures / Debugging / Using Breakpoints / Creating Field Breakpoints in Help for details. Obviously the String you are interested in needs to be a field and not a method variable. You can set the debugger to break anytime this field is either modified, accessed, or both. You can further set a condition to only break when a specified condition is true. A couple of caveats on using a condition...

1) Make the condition you specify is null safe to prevent null pointer exceptions from occurring when testing the condition. IDEA will warn you a NPE occurred and ask if you want to stop at the breakpoint. This just gets in the way. So keep them null safe. For example, for a String, use a condition of "my error message".equals(foo) rather than foo.equals("my error message"). Alternatively, you could use a condition of foo != null && foo.equals("my error message")

2) Setting the option to break when the filed is modified and a condition to break when "xyz".equals(foo) might be a bit counterintuitive on first glance. You might think this will cause the debugger to stop when the field is assigned the value "xyz", or is about to be assigned "xyz". It does not. It will break when the field is about to be modified and the value already matches that of the condition. So in other words, when the value you are interested in is about to be unassigned. To accomplish what you want, you would need to set it to break when the field is accessed and specify a condition such that the value matches the error string you are interested in. Obviously this will only work if the String is accessed, such as being passed into logging statement call, concatenated onto another String, etc. But it wouldn't make much sense for the String to be assigned and than never accessed. The down side is that the accessing of that String might not be in the same method. But if you just put your cursor on the variable name in the break line, IDEA will highlight any read accesses in light purple and and write access in light red. With that information, and the displayed call stack, you should be able to find where it was assigned.


If the item you want to watch is not a field, then you would need to set a breakpoint somewhere the String is used and set a condition on it to break when its value equals that which you are interested in. Such as in the call to log it or return it.

There are also Exception breakpoints which allow you to have the debugger pause execution any time the configured Exception occurs.

Hope that helps.

0
Comment actions Permalink

Hi Mark,

Thank you for the detailed explanation and a possible approach to meet our current need.

May be in the future releases the same concept could be applied on method return value, method parameters and local variables too.

Regards,
Nagendra

0

Please sign in to leave a comment.