When you run into a bug, IntelliJ will give you what’s called a “stack trace” that details the method calls that caused the error in the first place. One of the focuses of this lab will be to get you used to reading these stack traces, because they can be super helpful in debugging your own code.
Register for the lab using
grinch: https://grinch.caltech.edu/register and clone the repository as explained in the setup instructions.
Install the IntelliJ Visualizer
See the instructions here.
Goals and Outcomes
In this lab, you will enhance your code debugging abilities by debugging a text adventure we have written. We’ll guide you through this process, but the intention is to make this a realistic debugging experience.
By the end of this lab, you will…
- be able to read stack traces
- be better able to approach debugging code
- get experience with more of the kinds of errors you’ll run into during this course
Part 0: Run the (broken) Game and the (failing) Tests
The very first thing you should do is use the dropdown in the top right to first run through the game. This will give you a sense of what the program you are debugging is actually
supposed to do. Then, after you’ve run the game, run the tests; they should fail on
BirdCountingStage which will lead you into debugging the first error below.
Part 1: Debug
When a runtime error occurs in Java, a stack trace is printed to the console to provide information on where the error occurred and what steps the program took to get there. When running the tests for the first time, your stack trace will look like this:
The first thing to note is what kind of error occurred; this is shown at the first line of the stack trace. In this case, our code threw a
The lines beneath it represent the sequence of methods the program took to arrive at the error: the first line in the list is where the error occurred, and the line beneath it represents the line of code that called the method which threw the error, and so on.
NullPointerException that occurs in
BirdCountingStage by analyzing the stack trace that the program gives you. In general, you can ignore lines the lines
<XX internal calls>: these are contained in the test code and usually won’t give insight to the error.
It turns out that this isn’t the only error in this class!
IndexOutOfBoundsError that occurs in
Note: Ignore the grey links to
ArrayList.java at the top of the stack trace. The error happened in code that was not yours because of your code.
Part 2: Debug
Fix the error(s) in
SpeciesListStage. If you don’t see what the issue is while looking at the top line of the stack trace,
it’s sometimes a good idea to look at the second line to see where the method is being called from.
Hint: Consider the possible values of each list. Does the code account for them?
Part 3: Debug
Sometimes, IntelliJ will tell you something that it thinks is wrong. Hover over the orange highlights in the method with the bug. Does that give you any useful information? Use this feature to fix the error(s) in
Part 4: Still Broken :(
At this point, the first test should pass. That test is testing a correct input to the adventure game. The second test tests an incorrect input (meaning one that gets
something wrong at some point during the game). You should have gotten an
AssertionFailedError this time. That’s IntelliJ telling you that the output the game gave did not match
the output we expected it to give. Click on
<Click to see difference>. IntelliJ will tell you where the outputs differed. Specifically, in this case, the
a bug. Go back to the
SpeciesListStage and find the bug. (Hint: Use what you learned in task 4.)
To commit to the repository, click the green checkmark on the top-right of IntelliJ’s interface. A window will pop up and
ask you to type in a message. Choose some meaningful description of your feature, then click the little down arrow next to the “Commit” button on the bottom right of the dialog.
Choose “Commit and Push” in the little menu that pops up. If IntelliJ asks you if you’re sure you want to commit and push, say yes.
Checking the Results on
Task 7. Check to make sure you are passing all the tests on gitlab.
Getting Checked Off
At the end of every lab, you will need to call over a member of course staff to review your work. Sometimes, we will ask you to think about questions that you’ll review with the person who checks you off. For this lab, please answer the following questions:
Click the “Submit OpenEndeds” button below.
Then, call over a member of course staff by typing “
!question done” into your
workspace text channel. Someone will get to you as soon as possible.