Stop! Please be sure you fully read and finished doing all tasks in Homework 0: Introduction and Environment Setup before continuing.
We hope you had a relaxing break! This homework is intended as a refresher to help you gain familiarity with debugging techniques in IntelliJ, CIS 1210’s supported IDE. Becoming familiar with the IntelliJ debugger is a crucial skill that will help you succeed in CIS 1210 (and future CIS classes) as your programming assignments become increasingly complex! Additionally, before you come to TA Office Hours for debugging help in future programming assignments, we expect that you’ve already tried using the IntelliJ debugger – it really helps us help you debug a lot faster.
We have put together several stub files –– click here to download them.
2 files to submit: GradeHistogram.java
and BombMain.java
Please do not submit any additional files.
Be sure to follow these guidelines:
package src;
).[full]
.[full]
autograder that get 0 points (usually due to forgetting or misnaming a file) do not use up a submission.You will submit this and all future programming assignments on Gradescope, and you will learn more about how CIS 1210 uses Gradescope in the next part of the assignment. You should have been automatically added to Gradescope, and received a confirmation email if you are an enrolled student. If you are not yet enrolled in Gradescope, please email cis1210@seas.upenn.edu with your full name and the email address associated with your Gradescope account.
Follow these instructions to submit your programming assignment:
[FULL] HW0: Explosive Debugging
.
Clicking on these will open a window where you can submit your files.[full]
autograder once you’re ready! This is the
only one we will grade.Gradescope issues? Be sure to check out our Gradescope help page before posting to EdDiscussion.
To ensure that you understand the collaboration policy, we are requiring that everyone completes the collaboration policy quiz on Gradescope independently. It’s pretty simple, and you’ll get instant feedback on your answers.
If you have any questions about the policy, please reach out to the Head TAs.
Stop! Please complete the collaboration policy quiz before continuing to the rest of the assignment!
For this assignment as well as all other future programming assignments, an abridged version of the no collaboration policy is below. You can find the full policy on the homepage of the website. Make certain you understand our collaboration policy before continuing!
For this and for future assignments, we want to be very clear early on about the collaboration policy and clarify what is and is not allowed. If you are ever unclear whether something violates the policy, feel free to post to Ed Discussion or ask a TA. Any violation of the collaboration policy will be dealt with severely.
Not allowed:
You may not collaborate on any part of programming assignments. This
includes discussing solution strategies, sharing code, looking at someone else’s
code, helping debug someone’s code, using code from online forums (e.g. Stack
Overflow), sharing specific test cases, keeping code in a public repository,
etc.
Allowed and encouraged:
You may consult any official documentation, such as
Javadocs or
Oracle’s Java tutorials,
or any official course material (including the assigned textbook).
Please note that TAs must report any instances of cheating, including during office hours. Programming homeworks are automatically checked for similarity and similar homeworks are also brought up during grading.
GradeHistogram
(6 points)For this part of the assignment, we will approach debugging the code by trying to understand where the tests are failing.
To do that, we have to run the tests. One way to do this is to right click on GradeHistogramTests
and hit “Run GradeHistogramTests” in the menu that appears.
The JUnit tests that we have written should run – and all fail! Your job in this part is to fix the buggy code in GradeHistogram
to make them all pass.
While you can read the test code itself, we would recommend reading the test output instead. For example, click on the name of the first test
testAddGet
and read the resulting trace on the right. You should see that the code threw an exception, but where?
The blue text will link directly to the line of code that caused the exception! Your first task is to fix this exception by
determining what the error is in the code.
After you believe you’ve fixed the error, go ahead and run the tests again. If the tests no longer throw an exception, you’re ready to fix the next bug. Repeat this process until all the tests pass, and then move onto Part 2!
Up until now, you may have practiced debugging by placing print statements throughout your code to monitor the values of certain variables. When strategically placed, the output from these print statements may make the bugs obvious or help narrow down their location. This method is called print debugging. Though print debugging is a valid technique, it can be tedious deciding what to print and cleaning up your code after you are done, and it also becomes less helpful as the complexity of your programming increases in CIS 1210.
Interactive debugging is a technique by which one debugs by using an interactive tool, or a debugger. We will show you the basics of how to use IntelliJ’s built-in debugger – please take this seriously and use this as an opportunity to become familiar with the tool! Learning how to use an IDE’s built-in debugger will help you tremendously in CIS 1210 and future CIS classes, and in future programming assignments, we expect you to have used it before coming to TA Office Hours so we can help you debug a lot faster.
Before starting the IntelliJ debugger, you should set a few breakpoints. Breakpoints mark places in your code where you can suspend the program during a debug session and examine its state. This allows you to easily examine the values of multiple variables without needing to write print statements!
To set a breakpoint at a line or a method, click in the gray area next to the line number:
A red circle or diamond should appear where you clicked. When the debugger reaches this point in the program, it will pause before the execution of the line or method. If you click anywhere on a line of code that has a breakpoint, a lightbulb icon will appear on the left and you can click on it to find more options regarding that breakpoint.
Once you have set some breakpoints, you are ready to start a debugging session! You can do this by clicking on the icon in the top right of the IntelliJ interface. The selected program should run until it hits its first breakpoint. Alternatively, you can debug a specific test by right-clicking on the test in your code and selecting “Debug.”
You should now see a debugger window appear on the bottom of the interface, where the console was:
Under “Frames”, you will be able to see all current method calls, and under “Variables”, you will be able to see the values of instantiated variables at this point in the program (they will also be shown in gray text in the editor). From here, you have a few options:
Sometimes you may want to have your program pause only on certain conditions. To do so, create a breakpoint at the line of interest and open the “Edit breakpoint” menu (by clicking the lightbulb or right-clicking the breakpoint icon itself). There, you can enter a boolean condition such that the program will only pause at this breakpoint if the condition is true.
Another thing you can do is to set breakpoints for exceptions in Java. If your program is crashing, you can have the debugger pause where the exception is thrown and display the state of your program. To do so, click in the debugger window and press the plus icon to create a “Java Exception Breakpoint”. In the window that should appear, enter the name of the exception that your program is throwing.
If you are curious to learn more about IntelliJ’s debugger, you can find the guide here.
The BombMain
class calls the phase methods of the Bomb
class. When you first run BombTests
, you will notice that the test is greyed-out and is terminated (because the bombs are exploding). Your job is make this test pass! Figure out the password to each phase by using the IntelliJ debugger. When you think you’ve figured out the password
to a phase, update the corresponding line of code in the BombMain
class so the correct password is passed into that phase method. When BombMain
has been updated
with the correct password to each phase, BombTests
should pass!
Trying to run through the code by hand is guaranteed to not work, and you are forbidden from adding print statements into the Bomb code – the point of this exercise is to get comfortable using tools that will help you a lot down the road. Please take it seriously!
To reiterate, in future programming assignments, we expect you to have used the IntelliJ debugger before coming to TA Office Hours so we can help you a lot faster!
The above parts together are worth a total of 30 points. Style and code coverage are graded on a subtractive basis with deductions as specified in the Setup and Logistics section of the writeup.
However, because the purpose of this assignment is to review debugging skills, we will not be assessing you on style and code coverage. In other words, if you pass all of the tests we have written for you locally, you should receive full credit for this assignment.
You are now ready to move on to the fun part of the assignment, Homework 0: Maze Solver.