Learning the JavaScript debugger Venkman
a Venkman guide that's slightly more useful then a towel
The ability to use breakpoints is one of the most important in large scripts, and therefore, this section is also one of the most pertinent. In Mozilla, move to the next file, venkman_example_6.html.
Using only stepping and the debugger keywords both has their
drawbacks. Firstly, by stepping, you're forced to step through all
the steps of a script, and the debugger keyword must be inserted in the
actual code. If you decide you wanted a stop here or there, too bad, either enter
it in the source, and start over, or step by step, work your way there.
This is where you need breakpoints.
Understand, that a breakpoint acts much like the debugger
keyword. It causes Venkman to halt, but only if the line is reached by executing
code. A breakpoint will only be used, if the line it's on is executed.
So it goes without saying, that you can only set them on lines with actual
code.
That said, there exists two kinds of breakpoints. Hard breaks can
only be set inside functions, and acts much like the debugger
keyword, causing Venkman to halt, just before the line is executed.
The other kind, is called a future breakpoint. This represents a "promise"
from Venkman, to halt as soon as possible. This kind of breakpoint is mostly
used in top level code. We'll look at each in turn.
When loading a file into the sourcecode view, the possible locations for a hard breakpoint is indicated with a line in the far left grayest margin.
Figure 46.
Possible places for hard breakpoints in this code on line 9, 10, 14 and 15.
As you can see, the "-" indicate the location for a hard breakpoint. Try clicking once on the "-" on line 15, it should change into a red "B".
Figure 47.
Setting a hard breakpoint on line 15 (click for unscaled version).
As you can see from figure 47, setting a breakpoint, causes it to popup in the Breakpoints panel (that's what it's for!). Further, notice that in the Loaded Scripts panel, that the usual blue box now has a red dot. This indicates that in this function, a breakpoint has been set. You can use either as a shortcut to the breakpoint. Clicking the function will highlight the function code in the source code view. Clicking the breakpoint in the Breakpoints panel will jump straight to the line.
Now, go back to Mozilla, and reload. You'll notice (much like using
debugger keyword), that Venkman jumps right back up.
Figure 48.
Script has halted on line 15, note that the Interactive Sessions
shows the value of a (click for unscaled version).
For now, ignore that a lot more lines suddenly shows possible
breakpoints (we'll get to this next). Just check out a's value,
or something similar. Next, move up to line 10, and set a hard breakpoint there.
Once this is done, press "Continue". You'll notice Venkman halting at the
breakpoint you just put in. You can keep moving through code like this,
for as long as you want, or until the script finishes. Setting a breakpoint,
pressing Continue, scrolling, setting the next (or set them all at once.)
Figure 49.
Stopped at the next breakpoint on line 10. Note that first
I used the Interactive Session to check, and then set the value of
b.
That's basically all there is to hard breakpoints. All there is to remember, that hard breakpoints can only be set inside functions.
If you want to remove a breakpoint, it's as simple as clicking the "B", so that it turns into a "F", and then once more, so it turns into a "-", thus clearing the breakpoint.
Once a file has loaded, and is statically sitting there, you can only set hard breaks inside of functions. If you need to set something which exists only in the top level, you can set a so called "future" breakpoint. Which basically means, that if a file, from the same URL as the current one is loaded, and if executable code exists at the line number where a future breakpoint was set, Venkman will halt as soon as possible (I know it sound weird, but I don't really get it either.)
Reload the page, and clear all breakpoints. It should look like in figure 46. Now, click on line 4, and you'll notice an F appearing. Also try setting one on line 5, an empty line (and F will likewise appear.)
Figure 50.
Setting a future breakpoint at line 4 and 5.
If you go back to Mozilla, and reload the page, it'll stop right at line 4 (and you'll notice the F turned into an B). This is because in this file, from the same URL, there was executable code on line 4.
If you press "Continue", you'll notice that the script raced right past your second future breakpoint. Because there was no code there that could halt it. Also note, that once a script is actually executing, it's able to tell ALL places that breakpoints will be possible. Note the inclusion of line 17 as a possible place. Clicking there, gives a red "B".
Figure 51.
Once a file is actually executing, Venkman can tell all locations
where breakpoints are possible. Note that the second future breakpoint
is still just a orange future mark, since Venkman can't stop at that line.
You don't really have to care much about the difference between hard and future breaks, just that future break are the only one you can set in the top of a script. It might seem confusing, with both types of marks, but really, it's not. Usually, you can plainly see where Venkman can and can not stop.
For those who care (and can understand), it seems the reason so called Future breakpoints are needed, is because once toplevel code has executed, and no longer has any references, it get's garbage collected by the JavaScript engine, and thus it doesn't "appear" in the code anymore, and therefore Venkman can't set a real breakpoint in the same way.
Might seem logical, but it's important to know, that breakpoints are reused
over and over, every time Venkman comes to that line, to execute it. If you move
to the next file, venkman_example_7.html,
and set a breakpoint in the function f, on line 6, and then
run the script, you'll notice that each time f is called, the
script halts.
Each breakpoint has a series of properties attached, these properties allow you to create "intelligent" breakpoints, whose behavior is governed by conditions you decide. In Mozilla, move to the next file, venkman_example_8.html. Start Venkman, and set a breakpoint on line 5, and then right click anywhere on the same line, to bring the following menu up.
Figure 52.
Bringing up the context menu for breakpoints.
Click on the properties menu item, to bring up the properties sheet. We'll go through the options one by one.
Figure 53.
The property sheet for breakpoints.
Neither "Enable breakpoint" or "Clear breakpoint after first trigger" works for me, but if it works there, I hope it's pretty obvious what it does... :)
Tobias Hinnerup reports that "Clear breakpoint after first trigger" works in the latest Venkman version!
This is by far the most interesting part of the property sheet. When you
check the check box, you'll be allowed to fill in the body of a function
that will execute in the scope of the function, where the breakpoint
is located (the function is called __trigger__).
Start with filling this into the body of the function.
(note, you might have to make the property sheet larger, by dragging the
borders, before you can put code in).
a++;
After that, you must then decide what to do, for now, we just want to add extra code, without acting on the result (inserting debug code on the fly, essentially), so click "Continue regardless of result". It should look something like the following:
Figure 54.
Entering code in the breakpoint function.
Then click apply, and reload Mozilla. The returned numbers should all be one larger then usual:
1 2 3 4 5
Using the "Stop regardless of result" just halts Venkman, like a normal breakpoint does, allowing you to inspect the state of the program.
The "Stop if result is true" is more interesting though. It basically
allows your breakpoint to become a conditional breakpoint. Put the following
code into the body of the __trigger__ function.
return a%2==0;
This basically stops Venkman at the breakpoint, each time a is an even
number.
You might also have noticed that a parameter __count__
is passed to the function. This parameter indicates the number of times
the breakpoint has been passed. Say you only want to stop at the breakpoint the
first three times? Then you could use the following code:
return __count__<4;
Note, that count begins at 1, and goes up from there (this will only work, if the radio button "Stop if result is true" is checked of course). You can during debugging, reset the count so far, to whatever you wish, by using the "Trigger count" box, and just entering whatever number you want to.
The final radio button option is a an option that let's you return "early" with the result now (in stead of letting the function run it's course, and return normally.) Consider the following code:
if (a%2==0) return "a was even (" + a + ")";
else return "a was uneven (" + a + ")";
Should give you the following in Mozilla:
a was even (0) a was uneven (1) a was even (2) a was uneven (3) a was even (4)
The "Pass exceptions to caller", determines, if exceptions throw in the
function __trigger__, get passed to your code or not.
This is a great way of testing if your script handles errors well.
The last check box, "Log result", simply means, that asides from doing the radio button choice, it will also write the result to the Interactive Session.
For this to really work,
you need to actually return something. So the a++
example I gave first, will just give this in the log:
LOG: undefined LOG: undefined LOG: undefined LOG: undefined LOG: undefined
However, using the "a was uneven/even" example given just above, the following will be printed to the console (as well as Mozilla):
LOG: a was even (0) LOG: a was uneven (1) LOG: a was even (2) LOG: a was uneven (3) LOG: a was even (4)
Having finally dug deep into breakpoints, you may wonder what more Venkman could possibly have to offer. But there is more! The next section covers three major aspects of the debugger, which aid in performance measuring and debugging.