Wandering Thoughts archives

Please test your error paths

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.)

On storing source code in some non-text format

Every so often these days there is some agitation that program source code should not be stored as text but instead in some more intelligent and more abstract form, and just presented as text by editors.

This is the programming language version of the web's 'semantic markup only' movement, and it fails for the exact same reason that only a small fringe writes in purely semantic markup: the appearance of the text is important, it is not an afterthought. Programmers care not just about the meaning of their code but also how it looks, and they want other people to see it that way because that specific appearance is important to them.

(This implies that automatically reformatting source code to the viewer's preferred style is not going to pacify people.)

You can in theory store source code in an abstract representation that still exactly captures the appearance of the text, but then what is the whole mess and effort getting you?

(Plus, the other problem is that programmers hate editor lockin, and in practice that's what any such system starts with, open XML format or not; there is going to be only one editor that can easily edit the new storage format.)

This does suggest the one place where you can get away with this: situations where you already have a specific captive environment and are dictating a single style of code formatting anyways.