Historical errata for Debug It!

I suggest that the following will read better:
“You can buy any number on every other aspect of software engineering—design, code construction, requirements capture, methodologies, the list is endless.” -> “…, methodologies, etc.—the list is endless.”

“Although the approaches discussed earlier in the book apply to all bugs, certain types of bug benefit from special treatment.” -> “…certain types of bugs…”

“If you have fond a bug” —> “If you have found a bug”

In the “Joe Asks…” section: “Cacheing:” —> “Caching:”

Under “Root Cause Analysis”

“something when wrong” s/b “something went wrong”

Sidebar:
“entire team are all happy to use” —> “entire team is happy to use”

For “whereas other thrash around”, “other” should be plural.

“He was never able to explain to me why software that passed the tests was a bad thing, however.” sounds a little sarcastic. Maybe the architect in this particular case took things too far, but it’s worthwhile examining the concern I assume he has: that giving the tests to the developers enables them to “cheat”.

“Chinese wall” usually has the “c” capitalized.

With “worth it’s weight in gold”, it’s is not a genitive.

It should be “Dinkumware sells ….,” not “Dinkumware sell…”
Dinkumware is singular, isn’t it?

After “Here’s how we might use it:” […]
message.addHeader(“Accept” , “text/html,test/xml” ); <- text/xml

Thanks for a really top shelf and useful book Paul!

First para. “, the software itself notices when something is gone wrong […]” <- ? remove “gone” or use “has” not “is” :-)

About line 28 : “[…] help us debug problem in situ.” <- ? “a problem”

Middle of page : “And this is what running the test might look like the following:” <- ? “the following” could be deleted.

You may or may not wish to rephrase “the final solution”.

The text talks about versions 2.0 and 2.1, but the diagram shows versions 1.0 and 2.0

The following Java code is not valid

if(item = workQueue.lockWorkItem()) {
item.process();
workQueue.writeResultAndUnlock(item);
}

It is most likely intended to read

if(workQueue.lockWorkItem(item)) {
item.process();
workQueue.writeResultAndUnlock(item);
}

depending on how the workQueue API behaves.

An additional pedantic point: the unlocking should be under a finally clause such that there are no “lock leaks” due to unhandled exceptions. The more appropriate fix would be

if(workQueue.lockWorkItem(item)) {
try {
item.process();
} finally {
workQueue.writeResultAndUnlock(item);
}
}

I cannot help but disagree with much of Section 10.1 “Assumptions and Assertions”. This is perhaps a cultural approach between languages, with my primary language being Java. I prefer explicit checks on method parameters, with appropriate exceptions being raised - greatly simplified by the Google Collections API - than the author’s recommendation on the use of “assert”. For me, bad parameters should be discovered as soon as possible, using “assert” to catch them will only lead to difficult-to-track bugs on production deployments. In my opinion, “assert” is best used to check parameters in non-public APIs and for checking variables deep within an algorithm.

To be more explicit, on page 160, instead of writing

assert name.length() > 0 : “name cannot be empty”;

I much prefer the following (note, methods are static imports from com.google.common.base.Preconditions)

checkNotNull(name, “name”);
checkArgument(!name.isEmpty(), “name cannot be empty”);

which will result in a NullPointerException or an IllegalArgumentException, respectively, if name is faulty - and most importantly, will not be dependent upon whether assertions are enabled or not. “assert” is best used within internal code, not in public APIs (even if public between internal projects) or exposed to user input.

In the first paragraph of section 9.3 Automatic Builds:

“One the most important variables…” should be
“One of the most important variables…”