University of Toronto - Spring 1998
Department of Computer Science
CSC 148H: INTRODUCTION TO
COMPUTER SCIENCE
How to Bring a Bug to Office Hours
How to find a bug
First, of course, you should try to fix the bug yourself.
Debugging is an essential skill that you'll be honing through
extensive practise :-) over the next few years.
When you have a logical error, these are some general steps you
can take to fix it:
- Use every clue that Java gives you (the error message, the highlights
showing which line crashed and which method calls lead to it), together
with your powers of deduction to narrow your focus to a small piece
of code that is likely the source of your bug.
- Then use the VisualAge debugger, or just print statements, to see
what the values of the relevant variables are just before and just
after that small piece of code. If the before values are sensible
and the after values aren't, then you have successfully localized the
bug.
- Then get out some paper and TRACE THE OFFENDING CODE BY HAND.
Your trace will show you what's happening (and why), which will
not be what you wanted to happen (hence the bug!). Now you know
what needs to be fixed! If your trace indicates that the code
*does* do what you wanted (and yet step 2 tells you that it doesn't),
then there is an error in your trace. Do it again, being even more
detailed and accurate.
How to bring a bug to office hours
Before you bring a bug to office hours, you must first take steps
such as those described above to find it yourself. Almost all of
the time, those steps will show you the bug and you won't even need
to talk to us.
But if they don't (this might be because you have a misconception that
prevents you from doing a correct trace, for example)
then you can ask us for help. But we won't be interested in
looking at it unless you bring along:
- A completely up-to-date printout of your code.
If it has hand-written changes, we'll make you go get an up-to-date printout.
- An explanation of exactly what small piece of the program
it is that you've narrowed the bug down to.
This should be extremely short -- at most about 20 lines.
- Input and output from a test run
showing the state of affairs before and after the offending piece
of code is executed.
- Your careful and detailed hand trace of the offending piece of code.
Back to the
csc148 home page