Debugging Java

Debugging Java

4.5 2
by Will David Mitchell, Will David Mitchel

Write error-free programs from development to deployment! This unique resource shows you how to develop code that shuns bugs from outside sources and explains how to use Risk Factor Analysis (RFA) to estimate project costs and timelines accurately. Squash those bugs and deliver clean,smooth-running Java code.

Write Error-Free Programs from Development to

…  See more details below


Write error-free programs from development to deployment! This unique resource shows you how to develop code that shuns bugs from outside sources and explains how to use Risk Factor Analysis (RFA) to estimate project costs and timelines accurately. Squash those bugs and deliver clean,smooth-running Java code.

Write Error-Free Programs from Development to Deployment Kill Java bugs dead with the tips,tricks,and advanced troubleshooting techniques in this comprehensive volume. Debugging Java shows you,step-by-step,how to locate and eliminate common and hard-to-find rough spots in your applets and applications. You'll learn how to prevent bugs from hatching in your code,avoid scope creep,reduce deadline pressure using RFA,use text editors and macros to reduce errors,use debugging power tools,and eliminate multi-thread conflicts. Debugging expert Will David Mitchell even shows you how potential design and logic flaws can spark new features! When "it works on my machine" just won't cut it,use the hands-on solutions offered in this resource to exterminate Java bugs for good.

  • Learn the architecture of clean Java code and eliminate bad programming habits
  • Set effective traps to locate and squash Java bugs
  • Find,analyze,and fix object-oriented and procedure-oriented code errors and trouble spots
  • Use Risk-Factor Analysis to eliminate bugs caused by deadline pressure
  • Implement robust macros to cut errors and save time
  • Extend and train the Copy/Paste buffer to avoid typing errors
  • Identify and remove conditions that may lead to mutually conflicting threads

Read More

Product Details

McGraw-Hill Companies, The
Publication date:
Product dimensions:
0.97(w) x 7.50(h) x 9.25(d)

Read an Excerpt

Chapter 1: You'll Never Catch 'em all!

Bugs, that is.

I'll begin with a rash-sounding claim. In even the smallest program (that has input, output, and processing), it's impossible to construct tests that will locate all bugs!

Now, if that's true, is perfection but a dream? Should we abandon hope and resign ourselves to producing poor-to-mediocre code? God forbid! We who have learned one of the hottest programming languages in history must now strive to create programs so clean that the chances of anyone finding a bug are nil. That's why this book exists. Testing is one of the programmer's best tools for writing master-level code, but as you shall see shortly, testing is insufficient. For example, just before Christmas, 1999, astronauts upgraded the Hubble telescope's computers from 386 to 486 technology, while Pentium-Ill computers were flying off the shelves. NASA couldn't use newer CPUs because they needed four years to test the chips' imbedded firmware. After four years of testing, NASA still didn't claim their tests were exhaustive. Rigorous testing is not enough. I'll try to prove that statement.

The Proof

You may recall Heron's formula from high school trigonometry. Give Heron's formula the three sides of a triangle and it reveals the area. This formula is just complex enough to challenge early computer students, but we'll use it for a different purpose.

Pretend your task is to use input and output to test a computer program that implements Heron's formula. You are to build test cases. What kinds of data would you input and what would you expect for output? For example, youmight input

  • Integers 3, 4, and 5, and expect an integer area of 6.
  • Integers other than 3, 4, and 5, expecting a floating-point answer.
  • Various floating-point numbers as input.
Please put the book aside for ten minutes at this point and see how many kinds of input and output test sets you can devise. Use the worksheet on the facing page for your work. Further into this chapter, I'll present a rather long list, which is by no means comprehensive.

Neither Debugging nor Testing Finds All Bugs

Teaching university computer classes, I would give the students a ten-minute, ungraded quiz, asking them to devise all the kinds of test data they could for the hypothetical Heron's formula problem. Then we'd tabulate the results. Most classes found 15-18 examples. Occasionally, succumbing to the ultimate bug, a student would write a computer program to solve Heron's formula! That always got a laugh. After ten minutes, I'd propose a few clever ideas found by previous classes and challenge the students to find more. In the ensuing fun, they would invariably expand the list to 30 or more, and I'd add a couple of items to my personal list. I did this as much for research as for teaching.

One conclusion is that testing is a highly creative and intuitive process. It is quite difficult to think of an exhaustive set of tests. None of my students or colleagues ever did, nor have I. Without an exhaustive set of tests, how can testing find all bugs?

Even if a tester could write an exhaustive set of test classes, such a set is insufficient. For example, one of my best students discovered something amazing about the Pascal compiler. At random, he input 16, 20, and 12.50613300415 into his Heron's formula program, and his program printed 101.001. So far, so good. The second part of his assignment was to round the results to two decimal places. He expected 101.00 and got an erroneous 101.01 instead. The Pascal compiler rounded incorrectly! However, 101.002 rounded correctly. So did 101.0001, 101.0011, and 101.005 .

He proved it was the compiler at fault, and then wrote a new program to test the compiler for further errors. His new program compared the compiler's rounding function with the standard algorithm that rounds numbers. If the comparison revealed a discrepancy, his program printed it.

The first design was to step through all possible floating-point numbers allowed by the quad-precision VAX compiler. When it became apparent this program would consume the VAX for most of the semester, he restricted the program's range. In four evenings, checking billions of possibilities, 101.001 was the only erroneous example it found. We wrote a letter to Digital Equipment Corp. (DEC) and received a kind response. Later, we received a note that DEC had fixed the problem...

Read More

Customer Reviews

Average Review:

Write a Review

and post it to your social network


Most Helpful Customer Reviews

See all customer reviews >

Debugging Java 4.5 out of 5 based on 0 ratings. 2 reviews.
Guest More than 1 year ago
Debugging Java is an excellent book on debugging and writing bug free Java code. While the book is aimed more at beginning and intermediate programmers, having all these techniques contained in one place makes this a valuable resource. Rather than mechanically show you with endless examples the different kinds of bugs, the author takes a different route and discusses them from a higher perspective, including where you are likely to find them and how to prevent them. He also includes some unconventional methods for preventing some types of bugs, some of which was good, some of it less so.
The book is well organized for the most part, although there are places where the author goes off on a tangent. Although Word can be used to prevent certain kinds of bugs, the placement of this and other less conventional techniques merited a section of their own.
My other complaint with this book is that some of the specific information regarding IDE's and such are quite out-of-date. While Visual Cafe was just recently pulled from the market, other IDE's have been gone for sometime, and anyone who has been around Java for more than a couple weeks will have heard of the IDE's and other Java tools listed in the book. But in the end, some of the information is valuable enough that I'll be re-reading portions of this every year as a reminder and checkup on my coding practices.
Guest More than 1 year ago
Warmest greeting from San Diego! ... You know, I may be the most fortunate man on earth, and not just because a major publisher called out of the blue and asked me to write the first and only book on 'Debugging Java.' Such a cool thing almost never happens to authors! ... I just love this language! ... BN.Com required me to give the book a star-rating, so I swallowed my humility and did. Here's why I give it five stars. Hope you agree. ... When I taught computer science at Nebraska, my classes invariably outscored other instructors' classes by a huge margin, on standardized tests. We discovered it was because I was the only one who taught students how to use the debugger. As a result, my students quickly discovered why/where their programs didn't work, fixed them, and had time left to learn what they had missed in class. Debuggers let them play with bugs, learning how to recognize and prevent them. The other students had to panic around, head-in-hands, trying everything but the kitchen sink, until some incomprehensibly random set of circumstances worked. Then, these very smart people would breathe a sigh of relief and go forget their pain at some party. Notice the word 'forget.' Been there? Buy that t-shirt? Well, I was one of that band's groupies! ... I determined never to visit such pain on my friends and students, and the astounding results got me in trouble with the dean, until we figured out why my people did so well. ... The moral is clear. If you want to be a Java master, learn to debug. If you want be the most productive person on your team, learn to debug. If you want to be the one who's always answering questions posed by other team members ... 'nuff said. ... You know, in 1999, Java stormed past all languages but VB to become the hottest compuer language on the planet, and the second most popular. Nobody can find enough Java programmers, especially great ones. Java's unique architecture scorns most kinds of bugs, yet its massive powers introduce entire new classes of errors that are particularly treacherous. As a result, 'Debugging Java' doesn't read like other computer books. It cannot, and be effective. It had to take new tacks. There are unexpected, new paradigms to discuss. ... For one thing, you'll enjoy a chuckle when you least expect it. Master orator Zig Ziglar taught me many valuable things, among them, how to toss out a one-liner every seven minutes or so during a presentation. If you like a laugh, you'll find one when you least expect it. As Zig says, a laugh goes so very far toward helping someone digest the driest point. All of the jokes and stories have Java points, to help you remember the important ones from several perspectives. ... The focus is on your bottom line--your personal value to your company. Your boss wants you to reduce not errors, but the cost of errors. Your value to him or her is directly proportional to how effectively you do that. So, 'Debugging Java' begins before the beginning of your project. 'Debugging Java' tries to help you find better ways to think, to view bugs, and to prevent them from ever hatching. If a bug never hatches, was it ever a bug? ... Or is your typical situation more like what my friend Dennis described when he exclaimed with exasperation, 'Why is it that we have to fall through the holes in the floor, to find them?' ... The book continues through the whole development cycle, stressing ways to find bugs early, when squashing them is cheap. It shows how to use the most powerful and popular debuggers on the market, and makes a strong case to take to your boss so he or she will buy them for you. Some are very pricey, and worth every buck. And yes, you need a second computer on your desk. Take the book to your bosses and show them powerful economic reasons why. ... Java's threads are potent, yet treacherous. Without thread debuggers, few people stand a chance against thread-bugs. 'Debugging Java' shows how to prevent/repair thread-related p