| | | Debugging Tips |
As your labs become more complicated and your knowledge of the syntax of Grace grows, you will discover that the type of errors you spend most of your time dealing with will change. The problems caused by errors involving the rules of Grace grammar will decrease and the problems caused by subtle logical difference between what you told the computer to do and what you meant to tell it will increase.
The process of removing such logical errors is called debugging. In recognition of its growing importance we want to give you four tips on how to approach it. The first two are ways to avoid complicated debugging problems in the first place, the third is a deep, guiding principle that us useful in debugging, and the last is a simple but very handy practical technique.
Having a good understanding of the problem you are trying to solve is important to successfully debug your program. We have been encouraging you to prepare for labs by outlining each different class in the code. In addition to making your lab time more productive, this practice forces you to think clearly about the problem we are asking you to solve and to explore some of the issues and potential pitfalls that will come up when you sit down in lab to write the program.
Compile and test your code after adding small parts. Never wait until you have typed in several long methods before you start testing. This will make finding syntax errors easier, and often can give clues to potential logical errors while the problem is still reasonably small. If you do this often, you will know what you have changed recently, which helps make the next item easier.
The minute your program malfunctions, you will probably have some idea what is wrong. Suppose for example, that while you are working on a two hoop Basketball game, where you score more points for the small hoop than the large, you reach the point where you think the onMouseRelease method is correct. However, when you run the program, the score is not changed in the right way for baskets.
You might attack the problem by carefully rereading the code you have written. This is a good idea, but it is not always effective. When we write incorrect code, the error often springs from a basic misunderstanding of how our instructions will be interpreted. When we reread them, we may stick with our misunderstanding and conclude that they should work as we had intended. In order to escape our misunderstandings, we have to uncover irrefutable proof that some small section of our code is just not doing what we expected. Then, we will have to admit that something about our understanding was wrong.
The trick is to find the small section of code that will force one to recognize the mistake quickly.
In the case of the Basketball example, there are several sorts of mistakes that could cause the problem.
This is too many possibilities. As long as there are so many possibilities, the debugger will tend, while looking at the code related to one possibility, to overlook the error and assume on of the other possibilities must be at fault. Narrowing things down to a single possibility is generally the best way to force oneself to admit a misunderstanding.
This brings us to the simple technique...
Consider the BasketBall problem again. How can we narrow the search for the error down from several possibilities to just one? The answer is to try to rule out one possibility at a time.
In this example, the easiest possibility to eliminate is the third -- wrong value is being added to score when the ball goes through the big hoop. How can we tell if this is the case? One approach is to add another line to our program which a) will produce some visible output, and b) will be executed exactly when the "if" is executed. Item (b) can usually be accomplished by putting the two lines right next to one another in the program.
Producing visible output isn't too hard either. We could construct a filledRect or a text. An even easier thing to do, however is to simply ask Grace to print a line of text. Grace has a separate pane in the editor in which such text appears. Each line displayed is just added to the bottom of the window. You don't have to specify a Location or a canvas.
Finally we started working on the design of the Frogger game.
| | | Debugging Tips |