Beginning JavaScript Third Edition phần 6 docx

Figure 10-10 Having corrected the mistake and reloaded the page, you should see the two times table in your web page, as shown in Figure 10-11. Figure 10-11 The second method you’re going to use to open the debugger begins with loading the page you want to debug into your browser; then you use the Break at Next Statement menu option under Script Debugger on the Internet Explorer View menu, as shown in Figure 10-12. 372 Chapter 10: Common Mistakes, Debugging, and Error Handling 13_051511 ch10.qxp 4/13/07 6:38 PM Page 372 Figure 10-12 You’ve already got debug_timestable.htm loaded, so select View➪ Script Debugger ➪ Break at Next Statement. Not much appears to happen, but reload the page by clicking the refresh icon or pressing F5, and the debugger will open at the next JavaScript statement executed. Where the next JavaScript statement occurs in your page depends on your code. If you have code in the page other than a function or code connected to an event handler, the first line the browser executes will be the next JavaScript statement. In your case, this is the code calling the following function: <script>writeTimesTable(2)</script> If there is no code in the page except code inside event handlers or functions, the next statement exe- cuted will be that fired in an event handler, such as the window object’s onload event handler or a but- ton’s onclick event handler. Note that with some setups of the script debugger, the browser brings up a dialog box saying that an exception of type “Runtime Error” was not handled. This does not mean that there is an error in the code, but is simply the way Break at Next Statement works. As you can see from Figure 10-13, the next statement executed in your example occurs when the browser reaches the script embedded in your web page that calls the writeTimesTable() function. Again, this script is highlighted in yellow by the debugger. 373 Chapter 10: Common Mistakes, Debugging, and Error Handling 13_051511 ch10.qxp 4/13/07 6:38 PM Page 373 Figure 10-13 You’re now going to use the Step Into icon, illustrated here, which can be found on the top toolbar. Click this icon and the debugger will execute the current line of code and move to the next line, in this case your function. (You’ll look more fully at stepping through code and examining the contents of vari- ables shortly.) You can also press the F8 key to step into the code, which is often easier than clicking the icon. Finally, let’s look at a third way of opening the debugger, which is probably the easiest and most useful. Imagine you want to stop your code’s execution and open the debugger just before the for loop is exe- cuted. You can do this by simply adding the keyword debugger to your script, which will stop the exe- cution at that point and open the debugger. Let’s do that now. You need to close the debugger, return to your text editor, and add the following code to debug_timestable.htm: function writeTimesTable(timesTable) { var counter; var writeString; debugger for (counter = 1; counter < 12; counter++) { writeString = counter + “ * “ + timesTable + “ = “; 374 Chapter 10: Common Mistakes, Debugging, and Error Handling 13_051511 ch10.qxp 4/13/07 6:38 PM Page 374 writeString = writeString + (timesTable * counter); writeString = writeString + “<br>”; document.write(writeString); } } Now refresh the page in Internet Explorer, and you’ll find that the debugger opens, with code execution paused on the line with the debugger keyword in it (see Figure 10-14). Figure 10-14 Again you can click the Step Into icon you used previously, and watch the code execute statement by statement. Stepping Through Code There are three important ways of stepping through code, each involving one of the icons from the top toolbar of the script debugger. You’ve seen that one way is to step into the code. This simply means that every line of code is executed on a line-by-line basis. If a function is called, you step into that function and start executing the code inside the function statement by statement, before stepping out again at the end and returning to the calling line. To do this you use the Step Into icon. You may find that having stepped into a function you get halfway through and decide the function is not the source of the bug, and that you want to execute the remaining lines of code in the function, then continue step by step from the point at which the function was called. This is called stepping out of the function, and to do it you use the Step Out icon. 375 Chapter 10: Common Mistakes, Debugging, and Error Handling 13_051511 ch10.qxp 4/13/07 6:38 PM Page 375 Instead of the icon you can press Ctrl+Shift+F8. There may also be times when you have some code with a bug in it that calls a number of functions. If you know that some of the functions are bug-free, then you may want to just execute those func- tions instead of stepping into them and seeing them executed line by line. For this the debugger has the Step Over icon, which executes the code within a function but without your having to go through it line by line. Or you can press Shift+F8. Let’s alter your times-table code in debug_timestable.htm and demonstrate the three kinds of step- ping action. Note that the debugger keyword has been removed from the writeTimesTable() func- tion and is now in the second script block. <html> <head> <script language=JavaScript type=”text/javascript”> function writeTimesTable(timesTable) { var counter; var writeString; for (counter = 1; counter < 12; counter++) { writeString = counter + “ * “ + timesTable + “ = “; writeString = writeString + (timesTable * counter); writeString = writeString + “<BR>”; document.write(writeString); } } </script> </head> <body> <div><script language=JavaScript type=”text/javascript”> var timesTable; debugger for (timesTable = 1; timesTable <= 12; timesTable++) { document.write(“<P>”) writeTimesTable(timesTable) document.write(“</P>”) } </script></div> </body> </html> Save this as debug_timestable2.htm. When you load it into your browser, the script debugger will be opened by the debugger statement, as shown in Figure 10-15. 376 Chapter 10: Common Mistakes, Debugging, and Error Handling 13_051511 ch10.qxp 4/13/07 6:38 PM Page 376 Figure 10-15 Click the Step Into icon and code execution will move to the next statement. In this case, the next state- ment is the first statement in the for loop in which you initialized the variable timesTable to the value of 1, as shown in Figure 10-16. Figure 10-16 377 Chapter 10: Common Mistakes, Debugging, and Error Handling 13_051511 ch10.qxp 4/13/07 6:38 PM Page 377 When you click the Step Into icon again, the timesTable = 1 statement is executed and you step to the next statement due to be executed, which is the condition part of the for loop. With timesTable set to 1, you know that the condition timesTable <= 12 is going to be true. Click the Step Into icon and the condition executes and indeed you find you’re right, the condition is true. Now the first statement inside the for loop, document.write(“<P>”), is up for execution. When you click the Step Into icon again it will take you to the first calling of your writeTimesTable() function. You want to see what’s happening inside that function, so click Step Into again and you’ll step into the function. Your screen should look like the one shown in Figure 10-17. Figure 10-17 The next statement to be executed is not the var counter; or var writeString; line, but instead the for loop’s initialization condition. The first two lines have been executed, but the script debugger does not enable us to step through variable declarations line by line. Click the Step Into icon a few times to get the gist of the flow of execution of the function. In fact, step- ping through code line by line can get a little tedious. So let’s imagine you’re happy with this function and want to run the rest of it. Start single-stepping from the next line after the function was called. To do this, click the Step Out icon. Now the function has been fully executed, and you’re back out of it and at the next line, document.write(“</P>”), as you can see from Figure 10-18. 378 Chapter 10: Common Mistakes, Debugging, and Error Handling 13_051511 ch10.qxp 4/13/07 6:38 PM Page 378 Figure 10-18 Click the Step Into icon to see that the document.write() line will be executed, and the next statement in the flow of execution is the increment part of your for loop. Click Step Into again and execution will continue to the condition part of the for loop. Clicking Step Into twice more brings you back to the call- ing of the writeTimesTable() function. You’ve already seen this in action, so really you want to step over it and go to the next line. Well, no prizes for guessing that the Step Over icon is what you need to click to do this. Click the Step Over icon and the function will be executed, but without your having to step through it statement by statement. You should find yourself back at the document.write(“</P>”) line. If you’ve finished debugging, you can run the rest of the code without stepping through each line by clicking the Run icon on the toolbar, shown after this paragraph. Let’s do that; then you can return to the browser and see the results of the code you have executed. You should see a page of times tables from 1*1=1 to 11*12=132 in the browser. Instead of clicking the icon you can also press the F5 key. 379 Chapter 10: Common Mistakes, Debugging, and Error Handling 13_051511 ch10.qxp 4/13/07 6:38 PM Page 379 Breakpoints Breakpoints are markers you can set in the debugger that force code execution to stop at that point and start single-stepping through the code. Load your debug_timestable2.htm page into the browser. This will open the debugger and stop exe- cution at the line with your debugger statement. Now imagine that you want to stop in your writeTimesTable() function on the line that writes the results of the times table to the page, namely document.write(writeString), as shown in Figure 10-19. This is the last statement in the for loop. However, we’re busy people and don’t want to manually step through every line before that. What you can do is set a breakpoint on that line and then click the Run icon, which will restart the code execution in the normal fashion (that is, without single-stepping). Then, when the breakpoint is reached, code exe- cution will stop and you can start single-stepping if you want. To set the breakpoint, you need to scroll up the code window in the debugger until you can see the line on which you want to put the breakpoint. Click that line; then click the Toggle Breakpoint icon on the toolbar, shown here. Any line with a breakpoint on it is indicated by the reddish-brown dot on the left of the code window and by the line itself being set to a reddish brown, although the line may not always be colored. You can set as many or as few breakpoints at one time as you wish, so if you want to break on other lines you can add breakpoints there too. To unset a breakpoint you just click the relevant line of code and click the Toggle Breakpoint icon again, and that toggles it off. To clear all breakpoints at once you can click the Clear All Breakpoints icon shown here (see Figure 10-19). Okay, now let’s start the code running again by clicking the Run icon in the toolbar. You’ll find that the code resumes executing without single-stepping until it reaches your breakpoint, at which point it stops. You can either single-step using the Step Into icon or click the Run icon again, in which case execution continues unless another breakpoint is reached. Leave the debugger open with code execution halted on your breakpoint; you’ll be using it in a moment. 380 Chapter 10: Common Mistakes, Debugging, and Error Handling 13_051511 ch10.qxp 4/13/07 6:38 PM Page 380 Figure 10-19 The Command Window While you’re stepping through code and checking its flow of execution, what would be really useful is the ability to check the values contained inside variables, to evaluate conditions, and even to change things on the fly. You can do all of these things using the debugger’s command window. Hopefully you still have the debugger open with execution halted at the breakpoint you set previously. The line stopped on in Figure 10-19 is repeated here: document.write(writeString); Let’s see how you can find out the value currently contained in the variable writeString. First you need to open the command window from within the debugger. You do this by clicking the Command Window icon, illustrated here, or by selecting Command Window from the View menu. In the command window, type the name of the variable you want to examine, in this case writeString; then click Enter. This will cause the value contained in the variable to be printed below your command in the command window, as shown in Figure 10-20. 381 Chapter 10: Common Mistakes, Debugging, and Error Handling 13_051511 ch10.qxp 4/13/07 6:38 PM Page 381 [...]... nicely function firstCall() { secondCall(); } function secondCall() { thirdCall(); } function thirdCall() { 383 Chapter 10: Common Mistakes, Debugging, and Error Handling // } function button1_onclick() { debugger firstCall(); } ... example function button1_onclick() { var x; x = 1 + 1; alert(x) } Top Frame Save this page as debug_topFrame.htm 3 86 Chapter 10: Common Mistakes, Debugging, and Error Handling Finally, enter the third page 0; factorialNumber ) { factorialResult = factorialResult * factorialNumber; } return... page as CalcFactorialTopFrame.htm Example function butCalculate_onclick() { try { if (window.top.calcFactorial == null) throw “This page is not loaded within the correct frameset”; if (document.form1.txtNum1.value == “”) . Transitional//EN” “http://www.w3.org/TR/html4/loose.dtd”> <html> <head> <script language =JavaScript type=”text /javascript > function firstCall() { secondCall(); } function secondCall() { thirdCall(); } function thirdCall() { 383 Chapter 10: Common. this page as debug_topFrame.htm. 3 86 Chapter 10: Common Mistakes, Debugging, and Error Handling 13_051511 ch10.qxp 4/13/07 6: 38 PM Page 3 86 Finally, enter the third page. <!DOCTYPE HTML PUBLIC. 10-25 Choosing JavaScript Debugger opens Venkman, as shown in Figure 10- 26. Figure 10- 26 389 Chapter 10: Common Mistakes, Debugging, and Error Handling 13_051511 ch10.qxp 4/13/07 6: 38 PM Page 389 The