AJAX In Action [278]
Licensed to jonathan zheng 574 APPENDIX A The Ajax craftsperson’s toolkit Figure A.6 The Mozilla Venkman debugger allows inspection of local variables in functions higher up the call stack than the current point of execution. Watching expressions Some debugger tools are capable of evaluating expressions on the fly and allow the user to predefine code expressions that will be reevaluated as the debugger moves across the code. These expressions can make use of any variables currently in scope, allowing the developer to interact with the program while it is running. Conditional breakpoints Setting a breakpoint at a particular point in the code can give a developer finegrained control over when to invoke the debugger, but in some cases, this control is not enough. When executing a loop, for example, any breakpoint inside the body of the loop will be executed each time the loop is executed. Let’s take the following example: Licensed to jonathan zheng Debuggers 575 for (var i=0;i<100;i++){ var divisor=i-57; var val=42/divisor; plotOnGraph(i,val); } Running this code causes an exception to be thrown midway through the loop. In this case, a quick inspection of the code tells us that this will happen when i is 57, and we attempt to divide by zero. However, let’s pretend for now that it isn’t so obvious, as will often be the case with real-world code. We suspect that the divisor being set to zero is the problem but don’t know when such a condition will occur. We could set a debugger breakpoint inside the loop: for (var i=0;i<100;i++){ var divisor=i-57; debugger; var val=42/divisor; plotOnGraph(i,val); } but we would need to click the resume button on our debugger numerous times to step through the loop to the point where we encounter the error condition. If we’re being clever, we can test for the error condition in our code: for (var i=0;i<100;i++){ var divisor=i-57; if (divisor==0){ debugger; } var val=42/divisor; plotOnGraph(i,val); } This will take us straight to the fifty-seventh iteration of the loop, the one at which our error condition occurs. We could describe this as a conditional breakpoint— that is, it will break the flow of execution only if a certain condition is met. We can set up conditions in this way only by modifying the code. However, if we are assigning breakpoints through the debugger IDE, we can set a condition on the breakpoint independently of the actual code (figure A.7). Some debuggers do support this facility, allowing the user to attach expressions to a breakpoint, and break the flow only if the expression evaluates to true. Changing the values of variables If we encounter an error condition, our program execution halts. In a debugging session, we may realize what the solution is but want to coerce the program into continuing anyway, in order to test some later piece of code under the current set of conditions. Licensed to jonathan zheng 576 APPENDIX A The Ajax craftsperson’s toolkit Figure A.7 Setting up a conditional breakpoint in the Mozilla Venkman debugger Some debuggers will allow us to do this by providing write as well as read access to local variables (figure A.8). In the case of our loop example shown previously, if we know that a divisor value of 0 is going to be problematic but want to explore some code following the loop, we could temporarily reassign a value of 1 to the divisor, letting the flow of execution continue. Figure A.8 Changing the value of a variable in a running program using the Mozilla Venkman debugger Licensed to jonathan zheng Debuggers 577 A number of debuggers for JavaScript are available. Free debugging tools include the Venkman plug-in for Mozilla Firefox and the Microsoft Script Debugger (see the Resources section at the end of this appendix for information on both of these) for Internet Explorer.