Break Point Ideas...

I plan to put these in as a feature request, but first I wanted to see if anyone knows of a way these ideas might currently be implemented...

1) conditional breakpoints. I'm iterating through a large list but I'm only interested in breaking into the code when a certain condition is met. The classic example being when a property of the current list element is a certain value. Currently I'm forced to put an 'if' statement in the code and reload the class in order to catch the required object.

2) Is there a plug-in that can turn on and off groups of breakpoints at a time. For instance, I might set up a group of break points that hit all the relevant spots in my connection pool, and another set that might effectively trace my budget management code and so on. I picture these groups being managed like the workspaces plug-in. If there's nothing out there that currently does it (and I believe there isn't) I might see if the PSI supports such things and see about writing it myself. Unless the genius who wrote the workspaces plug-in fancies making a kissing cousin implementation for breakpoints.

8 comments

Well, about no 1, why not enter a condition that looks a bit like this one:

list.get(i) instanceof MyClass ?
((MyClass)list.get(i)).isInteresting() :
false

Tweak and change it to suit your needs and your might be able to solve your problem.

As for no 2, I don't have any ideas; I fear it would be hard to design a UI that would be comprehensible enough for most people to actually use.

On a side note; most fellow developers I know, who have at least several years of experience, NEVER use conditional breakpoints - actually many of them are completely unaware of the functionality in their debugger aside from ordinary unconditional breakpoints.

I think that before making our tools even more sophisticated, we might need to spread the word on how to benefit from using existing features in the daily work.

Best regards,
Lars Ugleberg

1

alan brown schrieb:

1) conditional breakpoints.

Isnt it what IDEA call "condition" in the breakpoint settings of the
"line breakpoint"?

Have tried this some times ago, but found that this makes debugging very
slow. Dont know if this is true today.


Mario

0

Have tried this some times ago, but found that this makes debugging very
slow. Dont know if this is true today.


It is. The slowdown comes from the fact that conditional breakpoints are not
supported by JDI now, thus we have to stop at the breakpoint
and start the evaluation of the condition from out of debuggee process. I
don't know if SUN is going to support conditional breakpoints in 1.5 though.

Eugene.


0

Regarding #2: I don't know of a breakpoint, but there is already a feature request for this:

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

0

>On a side note; most fellow developers I know, who have at >least several years of experience, NEVER use conditional >breakpoints - actually many of them are completely unaware >of the functionality in their debugger aside from ordinary >unconditional breakpoints.

Well I do have several years of experience (if by several you mean 20 or so), and I did know of conditional breakpoints, but never used them. Until last week I was unaware of either exception breakpoints and logging-only breakpoints. These both deeply rule. Exception breakpoints mean no more trying to figure out error context from stack traces. Logging only breakpoints mean no more scattering the code with System.out.println. The ergonomics on these could be improved. For instance, I'd love to select an expression and have a "set logging breakpoint" menu command, or even an intention. That said, the functionality is simply amazing.

--Dave Griffith

1

Conditional breakpoints are there but are unusably slow :( This is not
IDEA's fault! What I nearly always end up doing is adding an "if" statement
(for my condition) with a arbitrary System.out.println() inside and put a
normal line breakpoint on that. The trick is remembering to remove this code
afterwards :) In fact, could IDEA not effectively do this for you behind the
scenes when you create a conditional breakpoint (by altering the bytecode).
Bit hacky but would be very useful and speed up conditional breakpoints
considerably?

Another thing I would love to see (but haven't seen anywhere) is breakpoints
that are conditional on the current stack trace. I quite frequently want to
set a breakpoint but only have it fire when I am in a given stack
(underneath a given class).

For example, I want to set a breakpoint on my FieldEditor's "setValue"
method but only have it fire when the FieldEditor is being called from
within a TableCellEditor (as I am debugging why it doesn't render correctly
when used in a table). I don't want to catch all calls to "setValue" as the
field editor is used in many different contexts. So the condition would be
(in this example) "stack contains javax.swing.table.TableCellEditor"!

Cheers,

TicH



0

1. IDEA does let you set up different todo patterns, so to handle just the case you're talking about, I set up a special "DEBUG" todo pattern, demarcating code that must be removed before checking in.

2. I wonder whether assert statements can be multi-line? This might be a way to set up conditional breakpoints that can be deactivated.

3. As a workaround, you could do the stacktrace-conditional breakpoints in code by using Exception to create stacktrace element arrays.

0

Richard Kent wrote:

Conditional breakpoints are there but are unusably slow :( This is not
IDEA's fault! What I nearly always end up doing is adding an "if" statement
(for my condition) with a arbitrary System.out.println() inside and put a
normal line breakpoint on that. The trick is remembering to remove this code
afterwards :) In fact, could IDEA not effectively do this for you behind the
scenes when you create a conditional breakpoint (by altering the bytecode).
Bit hacky but would be very useful and speed up conditional breakpoints
considerably?


Expect this situation to get a lot better with JDK 1.5. It introduces a new
feature called Dynamic Bytecode Instrumentation, which allows tools to
modify the bytecode of classes while they are running. This could be used to
transparently add the "if (condition) " construct you mentioned -
in fact something similar to this is mentioned as one of the suggested uses.

A similar effect may also be possible using Hotswap with JDK 1.4: IDEA would
have to do the bytecode instrumentation itself on the compiled class and
swap the entire class. A little awkward and slow perhaps, but probably
doable. Maybe a plugin...? :)

Vil.
--
Vilya Harvey
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/

0

Please sign in to leave a comment.