Debugging Nightmare

A Debugging session that you wish you could wake up from.

Here are some remedies to help you think outside the box:

The bonus is that when you've finished you will have some ProgrammerTests, and/or refactored code.

Brilliant ZenSlap/GentleSarcasm. Nicely done.
In addition to writing the tests, as suggested above, one needs to believe the tests. If the tests show that the area your are concentrating on is working, believe them and look else where. There are times refactoring reveals latent errors in surrounding code; just because the error appeared when you made a change, does not always imply the change caused the error. The vast majority of the time, an error can be traced back to the most recent change, so start looking there. If however, you have refactored once, fallen back to the old code, refactored a second time, and the error still pops out, try looking at the surrounding code for the problem.
I encountered a problem that escaped testing for the oddest reasons. I borrowed a date validation routine from the web that used the JavaScript "parseInt" function. I tested boundary conditions for month numbers such as 1, 12, and 13. However, months 8 and 9 sometimes didn't work because if you put a zero in front of the number ("08"), then parseInt assumes it is octal unless one explicitly gives it a second parameter indicating base. Thus, "12" works fine because it is not interpreted as octal because it does not start with a zero. Further, in some of my tests I didn't bother typing in a leading zero. Thus a date of "1/8/2005" would pass the test.

Since that problem happens to everyone, eventually, I wouldn't call it "for the oddest reasons", I would say that that's actually an excellent example of how well-intentioned tests can run afoul of mental blocks.

To veer this discussion in a slightly different direction, I would suggest that this is a prime example of a method screaming to be refactored; it is doing too much (Yeah, I know changing this is outside of our realm of feasibility, but it is a good example of the principle). It would have been much better to just create two methods, parseInt and parseOctalInt and allow the programmer to explicitly choose the function desired rather than try to make an implicit decision base on a data format. The point of this is not that there is anything one can do to prevent these types of mistakes based on external code, but that one should avoid this type of thing in code under one's range of control.

Well, the lesson to learn is to specify the base explicitly using "parseInt('08', 10)" instead of simply "parseInt('08')". This is an example of not using the library correctly (as well as an object lesson in JavaScript's poor ApiDesign).

JavaScript authors picked a stupid default behavior and should be slapped. Octal is probably like 0.001% of number usage in the field. I'd like to see their reasoning steps as an object lesson in how NOT to think when designing languages or general API's. Let's investigate the mental plane crash.


See Also: DreadedDayOfDebugging, BigBangTesting, HeisenBug

EditText of this page (last edited February 27, 2013) or FindPage with title or text search