<<Previous | ToC
| Next >>
When
your program is broken, when it doesn't do what you thought you told it
to do, we say "It has a bug." The term "bug" came out of the earliest computers,
which used mechanical relays to do their logic. One day they were getting
wrong answers and the technicians finally isolated the problem to a moth
that was trapped between the contacts of one of the relays, preventing
it from completing the circuit. Now everything is software, so instead
of technicians making circuit measurements with a volt meter, we have a
software program whose job it is to show what is happening inside your
program, and it is called a "Debugger" because its purpose is to help you
find (so you can remove) the bugs in your program. The debugger does not
find anything, you do that. The debugger merely shows you what you told
the computer to do, so it's easier for you to see how that is different
from what you wanted to tell it to do. Only you know what you wanted;
the computer only knows what you actually told it, and it does exactly
what you told it to do.
So here's the deal: I ran my Java Guessing Game, and well, it didn't work properly, like it wasn't seeing my input, other than to repeat the input loop (see screen shot).
If you are doing this in BlueJ, see special instructions here. Otherwise...
In the Replit tool menu at the left margin, there is a triangle+bar icon (next to line 19 above) which activates the debugger. It invites you to "add a breakpoint by clicking on the line number" but that has no effect. Click to the left of the line number in the source text panel, and it will plant a little blue dot there, which we call a breakpoint. Most IDEs it's red, like a stop sign. I put it on line 18, the line after the input in my code. Then I clicked the solid blue triangle on the left (not the green Run button at the top) and gave it the first input when it asked. When the execution got to the breakpoint, it stopped in the debugger, like this:
Debuggers generally give you these three things, which you also saw in the English debugger:
1. What subroutines called whom to get here (in this case we are still in the main, as you can see under the "Call Stack" title at the bottom left)Many debuggers also give you the option to step into a subroutine (so it stops at the first line inside), or else to step over it, as if the subroutine call were like any other line. If not, you can always set a breakpoint there inside the subroutine to get the same effect.2. The values of the local variables (some debuggers give also static variables and instance variables, others like Replit may not)
3. Your choice to
a. Kill the program (that would be the blue rounded square under the title "Debugger") because you now know what the problem is, or you know what to reprogram to help find a problem you don't yet know; orb. Execute one line of source code (the single ">" icon), so to see what that line does, or
c. Run full speed (the ">>" icon) until another (possibly the same) breakpoint is hit.
For now we are interested only in the "Variables" panel. Since I put the breakpoint right after the input call, I get to see the value in answer, which is 'y' (what I typed), but it's not equal to the 'Y' or 'N' that I am comparing it to on the next line. In Java text and character comparisons are case-sensitive (they are in Kitchen too, but it tries to be accommodating).
That's the problem: the Kitchen computer capitalizes single character input for me, but Zystem apparently does not. I wrote it a couple years ago, I guess I forgot. It happens. (Reminder to myself: Kitchen 1-character input capitalizes; add another line in Java to do the same) but for now you have a work-around. If you look up an ASCII character chart on the internet (or here, in "Need to Know"), you can see that the lower-case Roman letters are +32 higher in (integer) value than their respective capitals. Java probably has conversion functions that also work for foreign languages, but we're only looking for "Y" or "N". You could do the conversion in software, but the easy way is to test for both capital 'Y' and lower-case 'y' (and the same for 'N').
If it had not, then I would have stepped farther into the program to see if maybe the new top or bottom is not being set correctly. You never know what the problem is (if you did, you could fix it without the debugger ;-)
An important part of computer programming is being able to think like a computer, and watching the debugger step through and do its thing is a good way to learn that. Eventually you should be able to think through the steps without watching them most of the time. All of us need to look occasionally, because we make mistakes, and it's sometimes hard to see through what we are thinking (when it is wrong) to what the computer is actually doing.
Next: Rock-Paper-Scissors
<<Previous | ToC | Next >>
Revised: 2022 September 19