|
Bug Proofing Visual Basic - Updates
|
|
|
|
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 send mail to
errbugs@vb-helper.com.
|
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.
Absolutely correct.
|
