?? ch14.htm
字號(hào):
<HTML>
<HEAD>
<TITLE>Chapter 14 -- Squishing Bugs in Java Games</TITLE>
<META>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EE" VLINK="#551A8B" ALINK="#CE2910">
<H1><FONT COLOR=#FF0000>Chapter 14</FONT></H1>
<H1><B><FONT SIZE=5 COLOR=#FF0000>Squishing Bugs in Java Games</FONT></B>
</H1>
<P>
<HR WIDTH="100%"></P>
<P>
<H3 ALIGN=CENTER><FONT COLOR="#000000"><FONT SIZE=+2>CONTENTS<A NAME="CONTENTS"></A>
</FONT></FONT></H3>
<UL>
<LI><A HREF="#DebuggingBasics" >Debugging Basics</A>
<UL>
<LI><A HREF="#SingleSteppingCode" >Single-Stepping Code</A>
<LI><A HREF="#WatchingVariables" >Watching Variables</A>
<LI><A HREF="#UsingBreakpoints" >Using Breakpoints</A>
</UL>
<LI><A HREF="#DebuggingStrategies" >Debugging Strategies</A>
<UL>
<LI><A HREF="#BugPrevention" >Bug Prevention</A>
</UL>
<LI><A HREF="#ChoosingaDebugger" >Choosing a Debugger</A>
<LI><A HREF="#Summary" >Summary</A>
<LI><A HREF="#QA" >Q&A</A>
<LI><A HREF="#Workshop" >Workshop</A>
<UL>
<LI><A HREF="#Quiz" >Quiz</A>
<LI><A HREF="#Exercises" >Exercises</A>
</UL>
</UL>
<HR>
<P>
Wow, you've now finished two complete Java games! You're probably
feeling pretty good about your new Java game programming skills,
as you should. Without putting a damper on things, keep in mind
that you didn't have to worry much about bugs in those games.
Actually, you did have to contend with scorpions and tarantulas,
but I'm talking about programming bugs. As sobering as it might
sound, I have to admit that the games had programming bugs in
them prior to some heavy debugging sessions. Who knows, they might
even have a few bugs now that managed to slip by. Knowing all
this, it simply wouldn't be fair to teach you about game programming
without covering the often dreaded issue of debugging.
<P>
Today's lesson focuses on debugging as it applies to Java game
programming. As you go through today's lesson, keep in mind that
bugs are a natural part of the development process; as humans,
we simply are error prone. So you should embrace debugging as
a necessary part of the development process and accept the fact
that even your precious code will have bugs. I'll do what I can
throughout today's lesson to help you develop skills that keep
bugs to a minimum, but the rest is up to you.
<P>
The following topics are covered in today's lesson:
<UL>
<LI>Debugging basics
<LI>Choosing a debugger
<LI>Debugging strategies
</UL>
<H2><A NAME="DebuggingBasics"><B><FONT SIZE=5 COLOR=#FF0000>Debugging
Basics</FONT></B></A></H2>
<P>
Before getting into any type of discussion regarding game debugging,
let's take a moment to define exactly what a bug is.
<P>
A <I>bug</I> is simply a coding error that results in some unwanted
action taking place in your game.
<P>
This unwanted action can vary, from a score not being updated
correctly, to the user's computer going down in flames. Although
the latter case is admittedly a little exaggerated (especially
in Java programming), you should take bugs very seriously because
they speak volumes about the quality (or lack of quality) of your
game.
<P>
The concept of bugs has been an accepted part of programming for
a long time now. Although all programmers strive for perfection,
few are ever able to attain it. Even those that do reach that
nerd nirvana typically encounter significant numbers of bugs along
the way. The difference is that these programmers anticipate bugs
rather than suggest that their code is immune to bugs. Therefore,
the first rule in regard to debugging is to assume that bugs are
in your code and that it is your responsibility to hunt them down
and fix them to the best of your ability.
<P>
The issue of finding and fixing bugs is especially important in
games, because game players are often very fickle. If a game does
something screwy like trashing a player's score, the player will
probably get frustrated and toss your game. This makes it all
the more important to be vigilant in finding bugs before you release
your game. Sure, you can always distribute a patch to fix a bug
in a release version, but it typically leaves game players with
a less than high opinion of your development ethic.
<P>
Before getting into specific debugging strategies, let's go over
a few debugging basics. If you are already familiar with debugging
in Java or in another language, feel free to jump to the next
section. The following are three fundamental debugging techniques
that you will find indispensable when finding and fixing bugs
in your games:
<UL>
<LI>Single-stepping code
<LI>Watching variables
<LI>Using breakpoints
</UL>
<H3><A NAME="SingleSteppingCode"><B>Single-Stepping Code</B></A>
</H3>
<P>
A very common debugger feature is the capability to single-step
through code.
<P>
<I>Single-stepping</I> is the process of executing your code one
line at a time (in single steps).
<P>
The significance of single-stepping as a debugging technique is
that it provides you with a means to see exactly what code is
being executed, along with the ability to trace the flow of execution
through your program. Typically, single-stepping in itself isn't
entirely useful; you usually combine it with another technique
known as <I>watching</I> to see what happens to variables as you
step through code.
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Note</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
Incidentally, a <I>debugger</I> is a software tool specifically designed to help you find bugs by letting you analyze your code as it is running. The Java Developer's Kit ships with a debugger called jdb, which you learn about a little later today in the
"Choosing a Debugger" section.
</BLOCKQUOTE>
</TD></TR>
</TABLE></CENTER>
<P>
<H3><A NAME="WatchingVariables"><B>Watching Variables</B></A>
</H3>
<P>
<I>Watching</I> is a technique that involves specifying certain
variables in your code as watch variables.
<P>
A <I>watch variable</I> is a variable whose contents you can see
while code is executing in a debugger.
<P>
Of course, in the context of a program running at normal speed,
watch variables don't help much. But if you watch variables as
you single-step through code, you can gain lots of insight into
what is happening. Very often, you will find that variables values
are changing unexpectedly or being set to values that don't make
sense in the context of what you thought the code was doing. This
type of insight into the inner workings of your code can lead
you directly to bugs. Single-stepping combined with watch variables
is the standard approach to finding bugs using a debugger.
<H3><A NAME="UsingBreakpoints"><B>Using Breakpoints</B></A></H3>
<P>
Another fundamental debugging technique is that of using breakpoints.
<P>
A <I>breakpoint</I> is a line of code that you specify, which
halts the execution of a program.
<P>
To understand the usefulness of breakpoints, imagine that you
are interested in a line of code in the middle of a program. To
get to that line of code in the debugger, you would have to single-step
for hours. Or you could set a breakpoint on that line and let
the debugger run the program like normal. The program then runs
in the debugger until it hits the breakpoint, in which case the
program halts and leaves you sitting on the specified line of
code. At this point, you can watch variables and even single-step
through the code if you want. You also have the option of setting
multiple breakpoints at key locations in your code, which is very
useful when dealing with complex execution flow problems.
<H2><A NAME="DebuggingStrategies"><B><FONT SIZE=5 COLOR=#FF0000>Debugging
Strategies</FONT></B></A></H2>
<P>
Although debugging tools have come a long way since the early
days of programming, the ultimate responsibility of eliminating
bugs still rests squarely on your shoulders. Think of debuggers
and standard debugging techniques simply as a means of helping
you find bugs, but not as your sole line of bug defense. It takes
a diversified arsenal of knowledge, programming practices, debugging
tools, and even some luck to truly rid your games of bugs.
<P>
Debugging can almost be likened to a hunt: You know there is something
out there, and you must go find it. For this reason, you need
to approach debugging with a very definite strategy. Debugging
strategies can be broken into two fundamental groupings: bug prevention
and bug detection. Let's take a look at both and see how they
can be used together to help make your games bug-free.
<H3><A NAME="BugPrevention"><B>Bug Prevention</B></A></H3>
<P>
Bug prevention is the process of eliminating the occurrence of
bugs before they have a chance to surface. Bug prevention might
sound completely logical-and that's because it is. However, surprising
numbers of programmers don't employ enough bug prevention strategies
in their code, and they end up paying for it in the end. Keep
in mind the simple fact that bug detection is a far more time-consuming
and brain-aching task than bug prevention. If you haven't understood
the point yet, I'm all for bug prevention as a primary way to
eliminate bugs.
<P>
Think of bug prevention versus bug detection as roughly parallel
to getting an immunization shot versus treating a disease after
you've contracted it. Certainly, the short-term pain of getting
the shot is much easier to deal with than the long-term treatment
associated with a full-blown disease. This metaphor is dangerously
on the money when it comes to debugging, because bugs can often
act like code diseases; just when you think you've got a bug whipped,
it rears its ugly head in a new way that you never anticipated.
<P>
Hopefully, I've closed the sale and you're set to employ some
bug prevention in your code. Fortunately, most preventive bug
measures are simple and take little extra time to implement. Unfortunately,
compared to other languages, Java is fairly limited in regard
to providing preventive debugging facilities. However, this fact
is a little misleading because the nature of Java removes many
of the bug creation opportunities available in other languages
such as C and C++. For example, the <TT>assert</TT>
mechanism is one of the most popular preventive debugging techniques
in C/C++. <TT>assert</TT> allows you
to check boolean conditions in debug versions of your programs.
A primary usage of <TT>assert</TT>
is to defend against the occurrence of null pointers. Because
Java has no pointers, you can immediately eliminate the risks
associated with this entire family of bugs. So, even though Java
doesn't have a bug prevention facility similar to <TT>assert</TT>,
there's no loss because in Java you can't create the bugs typically
found using <TT>assert</TT>.
<H4><B>Isolated Test Methods</B></H4>
<P>
A good way to prevent bugs early in the development cycle is to
test your code heavily as it is being developed. Of course, most
programmers do indeed try out their code as they are writing it,
so you're probably thinking that you perform enough testing as
it is. However, the type of testing I'm talking about is a thorough
test of your classes in an isolated manner. Think about it like
this: If you heavily test your classes in isolation from other
classes, don't you think the odds of bugs appearing when you connect
everything will be lower? Furthermore, think of how much easier
it is to test your classes early without having to contend with
a bunch of complex interactions taking place between different
classes.
<P>
My suggestion is to build a single method into each one of your
classes that puts the class through a series of tests. Call the
method <TT>test</TT> if you like,
and make sure that it handles creating instances of the class
using various constructors (if you have more than one), as well
as calling all the methods that can be called in isolation. I
know that, practically speaking, certain aspects of the class
can only be tested in the presence of other classes, but that's
all right; just test whatever you can.
<P>
In your <TT>test</TT> method, you
probably want to output the values of certain member variables.
Just output the results to standard output. If you are unfamiliar
with using standard output, don't worry. You learn about using
it for debugging later in today's lesson.
<H4><B>Exception Handling</B></H4>
<P>
One useful preventive debugging mechanism used in C++ is exception
handling, which also shares very solid support in Java.
<P>
<I>Exception handling</I> is a technique focused on detecting
and responding to unexpected events at runtime.
<P>
An <I>exception</I> is something (usually bad) that occurs in
your program that you weren't expecting.
<P>
Unlike some other forms of preventive bug detection, however,
exception handling also has a valuable place in release code.
<P>
To handle exceptions in your game code, you enclose potentially
troublesome code within a <TT>try</TT>
clause. A <TT>try</TT> clause is a
special Java construct that tells the runtime system that a section
of code could cause trouble. You then add another piece of code
(a handler) in a corresponding <TT>catch</TT>
clause that responds to errors caused by the code in the <TT>try</TT>
clause. The error event itself is the exception, and the code
in the <TT>catch</TT> clause is known
as an exception handler.
<P>
The following is some exception handling code that you've seen
a lot in the sample applets throughout this book:
<BLOCKQUOTE>
<TT>try {<BR>
tracker.waitForID(0);<BR>
}<BR>
catch (InterruptedException e) {<BR>
return;<BR>
}</TT>
</BLOCKQUOTE>
<P>
In this code, the exception being handled is of type <TT>InterruptedException</TT>,
which specifies that the current thread was interrupted by another
thread. In some cases, this might not be a problem, but the code
following this particular code is dependent on images successfully
loading, which is indicated by the return from the <TT>waitForID</TT>
method. Therefore, it's important that the thread is not interrupted.
The only problem with this exception handler is that it doesn't
output any information regarding the nature of the exception.
Typically, you would have code here that prints information to
standard output, which you learn about a little later today in
the "Standard Output" section.
<P>
This discussion of exception handling really only scratches the
surface of handling runtime errors (exceptions). I strongly encourage
you to learn more about exception handling and how to effectively
use it. Fortunately, a lot of information has been published about
exception handling in Java, so you shouldn't have much trouble
finding useful references.
<H4><B>Parentheses and Precedence</B></H4>
<P>
One area prone to bugs is that of operator precedence. I've been
busted plenty of times myself for thinking that I remembered the
precedence of operators correctly when I didn't. Take a look at
the following code:
<BLOCKQUOTE>
?? 快捷鍵說明
復(fù)制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號(hào)
Ctrl + =
減小字號(hào)
Ctrl + -