In this tutorial you will be asked to download a Forté program. The program creates a random (but sorted) array of ten integers, and does a binary search for a given integer in the array. The binary search does not work correctly. The purpose of the tutorial is to demonstrate the use of Forté's built-in debugger.

1. Download and unpack the binary search program.
   1. Download the file http://www.cis.upenn.edu/~matuszek/cit594/Programs/binsearch.jar (by right-clicking on it and choosing Save Target As...).
   2. Unpack this file, using either the jar utility (jar xvf binsearch.jar) or any zip utility. This will give you a folder named BinarySearch.
      
      
2. Try out this program, either from Forté or from a browser. Notice that the binary search fails to find numbers in locations 0, 3, 6, and 9 of the array.
   
   
3. Start Forté (if you haven't already) and use Mount Filesystem... to mount the BinarySearch folder. (See previous tutorials if you don't know how to do this.) Open the binary search project.
   
   
4. In the Source Editor [BinarySearch] window, scroll down and look at the binarySearch method--it should begin on line 134.
   
   
5. Set a breakpoint on the line containing the first if statement in binarySearch (this should be line 135) by right-clicking anywhere on the line and choosing Toggle Breakpoint. The line should turn bright red.
   • A breakpoint is a place that the debugger will pause the program and allow you to view variables, the stack, etc.
   • The Toggle Breakpoint command should more properly be called Add/Remove Breakpoint; it adds a breakpoint if there is none, or removes on if there is.
   • If you try to add a breakpoint on the method header line (int binarySearch(...)), it looks like you can do it, but the breakpoint won't actually work, because there isn't any executable code there--it's just a description of the method.
   You can even set breakpoints on comment lines!
   
   
6. Start the debugger.
   1. In Forté's main control window, choose the Debugging tabbed pane. This opens a different set of windows: Source Editor (which is available in other tabbed panes as well), Output Window, and Debugger Window. Also notice that the set of debugging icons (immediately above the Debugging tab) has expanded. (This step can be omitted.)
   2. Choose Debug -> Start from the main menu, or click on the down-arrow/green-bug icon, or hit F5. Do not choose Build -> Execute or click the green triangle; this will run the applet as usual, without starting the debugger.
      
      
7. Get the applet ready to debug. Click the New Array button (more than once, if necessary) and type in a number that the binary search should find, but can't (a number that only occurs in position 0, 3, 6, or 9). When you click the Search button, the program will pause at your breakpoint and the debugging windows will appear (if they weren't already visible).
   
   
8. Examine the windows.
   
   
   • The line in the Source Editor window that had been red, to indicate that a breakpoint is set there, has now turned blue, to indicate that you are paused at this breakpoint.
     
     
   • The Output Window has two tabbed panes, neither of them currently very interesting.
     • [Output] is blank. You aren't doing any output.
     • [sun.applet.AppletViewer] tells you that you stopped at a breakpoint.
       
       
   • The Debugger Window has six tabbed panes, holding more interesting information.
     • [Sessions] tells you which debugging session you are in. You can have more than one debugging session open at once, though this doesn't strike me as a very good idea. Click on the icon to see some mysterious information about the session. OK, enough for that pane.
     • [Breakpoints] tells you about all your breakpoints, not just the one you have stopped at. Click on the hand icon to see some reasonable information about the breakpoint.
     • [Threads] -- I'll bet you didn't know you had so many going at once! Anyway, you don't really care about this, so let's move on.
     • [CallStack] has some good information in it. At the top you see BinarySearch.binarySearch: 135, which is where you are: class, method, and line number. Click on the key next to it, and you will finally see something really useful: your variables including array, left, right, and target, and their current values. (Why doesn't it show middle? Look at the Source Editor window for a clue.)
       • Clicking on the green ball next to a variable brings up information you knew already anyway.
       • Clicking on the key next to array shows you the values in the array.
       • Clicking on the key next to this gives you more information than you ever wanted to know about this BinarySearch object.
     • [Watches] is currently empty. We'll come back to this window when it's more interesting.
     • [Variables] tells you about all your variables, far more of them than you ever knew existed. The most interesting ones are at the top.
     • [Classes] tells you all about your classes, constructors, and methods--information you probably already know anyway.
       
       
     Clearly, Forté has a huge amount of information that it can show you, but you probably don't care about 99% of it. Let's focus on the useful stuff, and try to make the debugger do something useful.
     
     
9. You've seen how to examine the values of variables in some of the debugger panes. Here's another way: In the Source Editor [BinarySearch] window, move the mouse over a variable name, such as left. Don't click on the variable, just let the mouse hover over it. After a second, a tiny window pops up to show you the value of the variable. Test whether this trick also works for target, array, and middle. This technique is too slow for variables you want to examine often, but it's handy for examining variables that you seldom look at.
   
   
10. Here's the most useful way to examine the values of variables. Right-click on left and choose Add Watch.... The window that appears should have left in its text field (if not, you can type it in). Click OK. Do the same for right and middle (and array, if you like). Now go back to the Debugger Window and click the Watches tab. Notice what has been added.
    • Now might be a good time to resize a few things. We aren't interested in the right-hand side of the [Watches] pane, so grab the divider between the two panes and move it all the way to the right. Then resize the Debugger Window so that the information in it just fits, and move it so you can see both it and the Source Editor window at the same time.
    
    
11. Now it's time to step through the method.
    1. Choose Debug -> Step Over from the main menu, or press the F8 key. Notice that line 135 in the Source Editor window has changed from blue back to red. The next line (136) is now the blue line. The blue line is the one you are about to execute; red lines indicate breakpoints. Blue covers red.
    2. Look at the Debugger Window [Watches]. The values of the variables have not changed, since so far you have only done an if test. The variable middle is still undefined.
    3. Choose Debug -> Step Over from the main menu once again, or press the F8 key again. Now line 137 is blue.
    4. Look at the Debugger Window [Watches]. You have now declared variable middle and given it the value 4.
       
       
12. Here are some of the things you can try--each has a menu item (under Debug), an icon you can click, and a keyboard shortcut.
• Step Over [F8] -- execute this complete statement. If the statement contains any method calls, "step over" the methods--that is, the methods are executed, but the debugger doesn't "look down" into their execution. (However, if the method contains a breakpoint, the debugger will pause there and show it to you.)
  
• Step Into [F7] -- start executing this statement. If the statement contains any method calls, the debugger "steps into" the method and pauses at the first executable statement in the called method. If this statement does not contain any method calls, Step Into is exactly the same as Step Over.
• Step Out [Ctrl-F7] -- this gets you out of a method that you have stepped into. Use this if you have stepped into a method by accident, or if you have simply seen all you want to see of that method.
• Run to Cursor [F4] -- puts a temporary breakpoint on the line containing your cursor, and executes up to that point. Use this to skip over a bunch of statements that you aren't really interested in.
• Continue [Ctrl-F5] -- this executes all statements up until the next breakpoint that it encounters. If no more breakpoints are encountered, the program will continue to run until it is finished (or you quit it). Use this command when you have seen all you want to see at the current breakpoint.
• Finish [Shift-F5] -- use this to quit debugging. Since you might have multiple debugging sessions going at the same time, you will be asked to select which ones to quit. Chances are there's only one, and it's checked, so just hit OK.
  
  
13. Use these to find and fix the error in binarySearch (there's only one). If you have already spotted it, pretend you haven't, and play around with the debugger some more.
    
    
14. Don't quit yet! When you save your program (or when Forté saves it automatically), all your breakpoints and other settings are also saved. If you have finished debugging and fixed all your errors, do the following:
    1. Go to the Debugger Window [Breakpoints] and select all your breakpoints (click on the top one, then shift-click on the bottom one). Then right-click somewhere in the selected area, and choose Delete (or just hit the Delete key).
    2. Go to the Debugger Window [Watches] and do the same with your watched variables.
    3. Save your program (with File -> Save All). If the command is grayed out, that's because Forté thinks the current version is already saved; but it's wrong. Although debugger settings are saved with the program, Forté doesn't realize that the debugger settings have changed. Make some minor change to the program (I usually add and delete a space), and try again.
       
       
15. That's it. Happy bug hunting!