So we have begun our Jungle Safari, er..Debug Safari. Every time we want to look at an animal or a bird in detail, we need to stop. Every time we want to inspect a variable, see the stack, and what not, we need to break the program at some point — and hence we require breakpoints. There are a whole lot of features with breakpoints, let us start with the basics:
Let us start with the layout — this is just how we view this tab.
The division is between the breakpoints and the relevant details — if we just want the breakpoints, select “Breakpoints View Only”. Will come to what the details contain in a minute.
Before we start adding breakpoints, adding that we can sort them by Name or Creation time ->
Let us also Group the breakpoints by type -
We can look at other options later.. We still haven’t come to breakpoints, so let us put one breakpoint:
Multiple things to observe here — This breakpoint now comes under the type “Java Line Breakpoints” -> this is a breakpoint at a line.. aren’t all breakpoints a line break point — yes, all “explicit” breakpoints are line breakpoints — will become clear as we move one. We cannot anyway put a breakpoint explicitly beyond a line granularity. So one best practice is to “Not” to overcrowd your line.
Options:
Take a look at the “Hit Count” in the above — Stop when you see the elephant for the third time — this just says stop after so many hits -
Now lets look at “Conditional” — Let’s say don’t stop when you see a peacock, see when you see a dancing peacock. In our case, stop when i is even:
An interesting option is the sub-option of “stop when the value changes” ->
Keep that it will stop when the condition changes from true to false and vice versa. In this particular case, this degenerates to stopping at every hit since this condition alternates.. that’s how we beat the system :).
Trigger Points — The first line of defence:
We can enable a break point as a trigger point — Only if that break point is hit, other break points will be enabled.
What happens if there are group of trigger points? If any one of them is hit, the rest of the breakpoints are enabled and all the trigger points are disabled. Its like trigger points being the first line of defence.
How do you recognize a trigger point ? One with a T
One with a T being cut is a breakpoint enabled once the trigger is hit.
Now let’s play a game: How about the combination of these — namely — Trigger Point, Condition, and Hit Count. Let’s Look at these:
Trigger point + condition -> The condition has to be true
Hit Count + Condition -> Count is incremented only for condition? Take a guess..
At line 36, we want the program to stop when both the conditions are true — ie Hit count should be 2 and the i should be equal to 1. it stops, since there is no conflict here.. Now let us change the condition to i%2 == 0, ie i is even.
When will this stop?
In fact, it will not stop. Hit count will be incremented anyway. So if it has to stop, the condition has to be true at Hitcount == 2. So this is an && relationship.
Now if you put all the three on, then again its an && condition.
Note: I did find some inconsistent behaviour, trying to reproduce. If you hit upon an erroneous behavior please file a bug at https://github.com/eclipse-jdt/eclipse.jdt.debug/issues.
Tracepoints:
Put a breakpoint without really breaking there! — Tracepoints
Essentially they are conditional breakpoints which does not have a proper condition — Here it just prints out the value — we just want some print statements without disturbing the code.
Method Breakpoints — Entry/Exit
To put a method entry/exit breakpoint, just go to the outline view and say “toggle Method Breakpoint’
This puts a breakpoint in the entry of method. We can also go to the line number of the method declaration and add a breakpoint. How can we put exit breakpoints?
Click on Exit. This will put at all the return statements — in the case above, at line numbers 42 and 44 for method bar().
We can also put hit count here — in this case 2, only the second entry will be stopped.
Lambda Breakpoint
From the Run menu, click on “Toggle Lambda Entry Breakpoint”
This will get a breakpoint similar to Method one
Watchpoints:
Click on fields and put a breakpoint —
A watchpoint gets enabled
This has two fields — Access and Modification. Access is for reading and Modification for writing — Enabling them respectively will stop at read and write resp.
Exception Breakpoints
Click on the above icon to set breakpoints for Exceptions —
Here we add for AIOOBE.
And it has two options — caught and uncaught. Let’s look at them
line 7 — caught
line 16 — uncaught.
If there is an issue, check the master preferences
Make sure that this setting is as desired.
Another interesting option is the policy for recurring exceptions — we can set this to stop only for the first instance.
Helpful NullPointerException
Though not about breakpoints, this is a recent feature which tells which variable was null — for eg, in the following code:
the console output gives:
Exception in thread “main” java.lang.NullPointerException: Cannot invoke “Object.hashCode()” because “a” is null
at poc.XNullPE.foo(XNullPE.java:6)
at poc.XNullPE.main(XNullPE.java:9)
mentioning that “a” is null, not leaving the programmer to guess which variable was null.
Working Sets for Breakpoints:
click on the three vertical dots to get the menu below
Now we can create and add the breakpoints to a working set. And then what? Where should we use this?
Now we can group by working sets:
Others goto a default working set.. Enable/Disable can be done at a working set level
We can group by resource working sets as well
We can choose as per convenience. A common option is by type:
More “complicated” configurations also can be specified:
And we can view it as:
I guess its time to stop about the organization/grouping of breakpoints
We can of course export and import breakpoints — helps in sending this to colleague, for example for working together.
Now we have just stopped our vehicles — we need to study the fauna in detail, meaning..we need to now look at the variables.
