Please test your error paths

May 31, 2007

One of my peculiar traits is that I test error paths, sometimes obsessively. If I write an error check into my code, I am not happy until I have induced the error and watched the error check fire correctly. Judging from some of the code that I've seen this makes me a rarity, but it shouldn't be this way.

In fact, I sometimes think that explicitly testing error paths is more important than explicitly testing regular code paths. It is usually pretty obvious when regular code paths don't work (your program doesn't work), and handling errors well is often really important to avoid turning small problems into big messes, or even badly damaging things.

So: please test your error paths. Your users will thank you for it someday.

Of course, this is often easier said than done. Few languages or debugging environments make it easy to inject synthetic failures into programs, and creating real ones at the right points is often very tricky, especially if you don't want to disturb other people. My impression of the test driven development approach is that their answer to this is another layer of indirection, but I like to think that some language assistance could solve this more directly.

(In general, debuggers seem to be pretty light on features to intercept, monitor, and modify program execution in an automated manner. And don't get me started about system calls.)

Written on 31 May 2007.
« A gotcha with the automounter and loopback mounts
Why our Solaris fileservers still use the automounter »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu May 31 21:48:04 2007
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.