Customer Reviews

Debugging Java: Troubleshooting for Programmers

5 star:		(4)
4 star:		(4)
3 star:		(1)
2 star:		(3)
1 star:		(3)

 

 

This book is money. The ideas and concepts in this book will probably recoup the book's cost many times over every month you remain in the industry. It is hard to discuss technical matters in a clear manner. Will Mitchell does so with warmth, wit and humor. No mean feat in a technical book. This guy actually tries to explain his ideas, not impress us with his intellect. Probably 60% of this book will be useful long after Java is an old dusty language that people used to use. I think that just about everyone in data processing would benefit from this book whether they use Java or not. I have been programming for over twenty years and I wish I could have read this book in the beginning. I have learned most of these principles and ideas the hard way. The rest not at all until now.

First let me say I liked the writing style and it was enjoyable to read. I was able to finish the book cover to cover in 3 days of casual reading. I did get something useful out of the book. He talked about right-brain versus left-brain activity which I found interesting and helpful for my job.

I've made the mistake of reading Extreme programming and Refactoring BEFORE reading this book. So for example in this book the author spends great detail on how to count in a large switch case statement how many case: elements you should have and how to quickly check it. If you've read Refactoring by Fowler you would instantly hear alarms in your head telling you your NOT using OO corectly and that this bad code should be refactored. If you want a good OO/Design Patterns book I would recomend Cooper's book. You better understand Design Patterns if your going to code in Java or you will have a tough time when it comes to I/O and Swing classes.

Two finally points to make on the downside of this book.
1. The author mentions 'goto' and does not correctly tell the history of why the word is reserved. James Gosling at OPSLA on year informed the audience that a technical writer was documenting 'goto' and wanted him to explain it. When James did a grep against the code base he saw it used 10 times of which only 3 where valid in his opinion. James then decided it was easier to remove it than it was to have it documented. James felt that continue and break statements handled all cases that goto were being used in the system.

2. The exception model in C++ is just plain broken and the author does not do a good job of explaining what Java did to fix this problem. In a very large C++ system any 3rd party library could throw an exception that is un-advertised. Exceptions in C++ are checked at runtime. The Java compiler checks exceptions at compile time. In java you could never add a 3rd party jar file and have an exception thrown that is not advertised in the interface of the class or method.

Java is an OO language and to debug in Java you better know OO and you better understand threads and java.object or your going to have a long night. The author should have started here and delved deaper instead of wasting paper on MS Word and Word macros for coding.

Ah...
Before I forget. If you read the book PLEASE don't use /** QQQ*/
as a tag in your code. If you've got JBuilder use /** todo */ or something non-cryptic to document coding in progress comments.

A while back I picked up 'Debugging VB' and didn't think much of it. At first I thought 'Debugging Java' was better, but the author completely blew his credibility on three counts:

1. Not only does he recommend using MS Word as a Java IDE, he goes to some length to provide macros and so on to show how to achieve context-sensitive highlighting and so on. In fact, at the back of the book, several pages are devoted to this very thing.

2. At one point he writes with pride about how he whipped up a 'report generator' in Basic that cranked out 25 copies of boilerplate COBOL. Precisely the kind of code that Java's inheritance and object composition paradigms are intended to avoid. Some people never learn!

3. In a similar vein, he also takes about a faux Javadoc he developed that cranked out 1" of documentation in half a day. This fellow seems to prefer quantity over quality.

On the plus side, this book had a better-than-average discussion of the various IDE's (other than Word!), and is worth a quick peruse to see what they all look like, if you haven't already.

This is a great book. It is inusual in that it talks about techniques and methodologies rather than just reiterating a bunch of APIs. It discusses how to avoid bugs in the first place, and how to code defensively, and how to present abnormal conditions to users. It talks about how to cope with the inevitable deadlines, and how to design programs (like write the user manual FIRST, instead of last).

Every so often a book comes along that you know instantly must be read by all your colleagues. This is one of those books. I'm ordering a copy for each of my staff today, and we're going to decide which of the author's recommendations to adopt (maybe all of them).

Only about half of this book is really about "Debugging Java". The rest of the book could be titled "How to Develop Quality Software" and could be used with other languages (although if you care about quality software you're already programming in Java anyhow).

Buy this book. As soon as you get your hands on it make sure you write your name in it, because it'll get passed around a lot!

Nowadays there are a few Java books out there which are starting to catalogue common Java pitfalls ("Java Pitfalls" by Daconta et al, "Practical Java" by Haggar), but none of these actually focus on the entire debugging process. Come to think of it, I don't know *any* book which focusses purely on debugging software, full stop. When I spotted "Debugging Java" I therefore bought it virtually "on spec". Was I right to do so? In this rare instance, yes.

Mitchell's writing style is engaging, informal without being inaccurate, and in some places refreshingly unconventional. This book is clearly the author's considerable debugging knowledge condensed in one place. To give you a taste of how different Mitchell is compared to the majority of programmers (and book authors), Mitchell claims that he always guarantees his software for life: if clients find bugs in his deliverables, he fixes them... for free. Microsoft, IBM, Sun, Novell, and the other big guns, shame, shame on you for not being as quality-driven as one Will David Mitchell.

Given Mitchell's software product quality philosophy, it's no surprise that he has a few tricks up his sleave that the rest of us should also know. Buy the book and join the elite ranks.

This book is called Debugging Java, and it does have some Java specific content (like discussions of Java specific debugging tools), but its content can be applied to any language. Being a veteran programmer most of the tactics evangelized by this book I had already learned (many the "hard" way). Interestingly one technique that I find extremely useful, walking through each new line of code in the debugger, wasn't mentioned at all. Beginning to intermediate programmers will benefit the most.

While reading this book, be very careful about trusting the examples and descriptions because there are a lot of errors in the text and the examples. Some are obvious and trivial (like the "test stub" claiming that "a = 5; b = 5; a = b = 10;" will result in "a == 5" on page 235) others are less obvious and can cloud the points. Most of the philosophy discussed, however, is dead on. All-in-all a little depressing that in a book about bugs and testing the thing the book needed most was better editing.

I was disapointed to find that almost the last 100 pages of the book is fairly useless appendices (lists of Java applications that undoubtedly was out of date before the book hit the shelves, for example) including 20 pages of Word macros that would make Word into a questionable programmer's editor. If you can't afford a "real" programmer's editor like CodeWright, my current favorite, at least get a free version of EMACS, which is available on pretty much every platform. My opinion.

This book reads very well, and I truly enjoyed the afternoon spent perusing it. I would summarize it as presentation of a useful bag of tricks accumulated by the author, targeted at second year comp sci students. Be aware, though, that the author has not worked on large scale or complex problems, and his bag of tricks will need to be upgraded to more formal and robust approaches, common in the industry, as you try to tackle more difficult problems. For example, his 'write user manual first, then spec, then help file, then code' will need to be replaced by one of the formal sw development methodologies, his RFA will be replaced with one of the formal risk analyis techinques, his 'autolog debugging messages' will likely become a tracing tool allowing remote debugging and dynamic tracing levels, etc.
I was surprised to find out that the author did not focus more on testing and writing test cases, (after all, how else do you debug your code if not by running unit and system tests?), and code walkthroughs (after all, this would be the usual way of getting another pair of eyes, as he suggests), logging and tracing strategies (interactive debuggers are great, but they can not be shipped with the with the product and can not be turned on remotely to generate a log), etc.
If you are intested in improving your personal software development process, you may find books on PSP (Personal Software Process) interesting.
Overall, though, I found the author presenting a coherent point of view and I definitely found it worth the monetary outlay :-)

I try to look on the bright side of every book I read, and the bright side of this book is that everyone at the office got a good laugh when the CTO brought it in.

The author talks about the advantages to editing java files with MS Word over other editors meant entirely for text document writing (Wordperfect, and another editor that I'd never heard of, but which, I was told, was popular in the '80s) . It also talks about writing word macros to help, and has a small section on how you may have problems with Word appending '.doc' to your java source files.

Aside from choice of editing tools, the content itself is poor. This is not a book for anyone who has programmed before, it is not a book for those who are trying to learn Java, and it doesn't talk about debugging Java in any real sense, so I can't imagine who this book is for.

I am amazed, however, at the fact that I see these 'Debugging' books in prominent places at many bookstores. I haven't looked at any of the other 'Debugging' series, but either the publisher has tremendous clout to get these books put on shelves, or _Debugging Java_ is the black sheep of the 'Debugging' family.

Although it was probably not worth the price of admission his discussion on preventing bugs was useful. Essentially, if you have 1 week to do 2 weeks work you will produce buggy code.

To avoid deadline stress like this he recommends a system for estimating work that consists of estimating what it would take if you could write it off the top of your head and giving it a factor from 0 to 5? for how unaquainted with the component techniques you are. Then raise your intitial estimate to this power to get your estimate for how long you will take for this task.

However, I agree with all the other criticisms.

2 stars. Not absolutely aweful but I could write better.

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.