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.
Setup
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 BirdCountingStage
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 NullPointerException
.
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.
Task 1.
Fix the NullPointerException
that occurs in BirdCountingStage
by analyzing the stack trace that the program gives you. In general, you can ignore lines the lines
with <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!
Task 2.
Fix the IndexOutOfBoundsError
that occurs in BirdCountingStage
.
Note: Ignore the grey links to Objects.java
and 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 SpeciesListStage
Task 3.
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 PalindromeAnimalStage
Task 4.
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 PalindromeAnimalStage
.
Part 4: Still Broken :(
Task 5.
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). Go back to the SpeciesListStage
and find the bug. (Hint: Use what you learned in task 4.)
Task 6.
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 gitlab
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: