<<Previous | ToC | Next >>
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 toa. 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; or
b. 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.
<<Previous | ToC | Next >>
Revised: 2022 September 19