Writing a book is a lot like writing a 100,000+ word software project. Just as most large programs contain bugs, so to do most books.
In some ways debugging a book is harder because there is no compiler to check the text (spell checkers help but leave a lot to be desired).
This page contains a list of updates and corrections to "Bug Proofing Visual Basic." If you find a bug, please
12/29/98 Scott Carpenter correctly notes:
p230, fourth paragraph in "On Error Resume Next" section - says "Many
programs use On Error GoTo Next...". I believe this should be Resume
instead of GoTo.
1/7/99 Emery A. DeWitt found this:
There's a bug in the "improved" code for the self-test for the very first chapter. In the For loop of
LinearSearch(), you have the test:
If list(i) = target ....
twice in a row. The body of the first first one includes code to exit the function, so the second will never be hit on a true condition. Surely, the
second one should read
If list(i) > target
Of course, the method of returning failure from LinearSearch(), and the proactive code in the call, ensures that the program works correctly, even
though the second test is invalid. Was this a subtle "test" of your readers?
Uh, yea. This was a test ;-) Seriously, though, I should have tested more and caught this.
It's interesting to note that the way the program returns its failure code actually hides this bug.
I suppose we could add a test after the For loop (that we would remove in the final program)
that checked whether the previous argument was smaller than the target.
1/8/99 Emery A. DeWitt found another typo:
Dim attacker as object
Set attacked = New Player
Presumably, attacked should be attacker.