Is this worth having as a break point condition

I just discovered that break points can have conditions attached to them.

I have a piece of code that is hit whenever a user object is
referenced. I would like a way to break only if a specified method is
in the call stack. This would allow me to break only when the user
object is in the change password path, etc.

Does this seem usable?

--
Norris Shelton
Sun Certified Java Programmer

6 comments
Comment actions Permalink

Conditional breakpoints are already very useful as they are (they have saved me tons of debugging hours), but the improvement suggested by you would make them top-notch.

Please submit a tracker request (unless there is already one submitted) and share its number.

--Vlad

0
Comment actions Permalink

Here you go

http://www.intellij.net/tracker/idea/viewSCR?publicId=34902

Norris Shelton
Sun Certified Java Programmer




vlad wrote:

>Conditional breakpoints are already very useful as they are (they have saved me tons of debugging hours), but the improvement suggested by you would make them top-notch.
>
>Please submit a tracker request (unless there is already one submitted) and share its number.
>
>--Vlad

>

0
Comment actions Permalink

I use conditional breakpoints very rarely, because they slow down the VM so much. But, yeah, they do come in handy sometimes.
Still what I do most of the time instead of setting a conditional breakpoint is this: Insert the condition as java code to the source (with an additional statement to set the breakpoint on), recompile that file, hot swap. Full speed, not much more work. You could use this as well for your scenario:
In the method you want to have in the call stack increment a counter on entry and decrement on exit (

   } finally {
      --blub;
   }
}]]>

) and where you want the breakpoint to be:

 0) {
   int foo = 42; // breakpoint here
}]]>

Ok, ok not so pretty, but it works. I have to search every now and then for forgotten statements "int foo = 42;" in the code though ;-(

0
Comment actions Permalink

You would also also have to remember removing blub, etc. Sorry, but I don't find such an approach acceptable in the age of IDEA. I share the concern regarding debugger's speed, but I don't find the current conditional breakpoints triggering that huge of a slowdown (compared to "plain debugging").

BTW, I am a happy camper regarding IDEA's debugger: I think it's great and it can become top-notch!

0
Comment actions Permalink

As I said, it's a workaround - by nature it is inferior to a solution. If you don't think it is acceptable, then what is your suggestion how to handle that with the current Idea build?

0
Comment actions Permalink

Stephen,

I think we are on the same page, since I'm not discounting your approach when taken at face value (i.e. as a workaround). I am simply saying that it's a shame still having to rely on such workarounds when using such a smart tool as IDEA.

0

Please sign in to leave a comment.