http://www.mikeash.com/pyblog/friday-qa-2009-10-09-defensive-programming.html
This is an article about programming strategy and error handling on an abstract level.
I am still very much in the ‘trying to make it work’ stage of programming, but this article has made me consider a stage in application development that I hadn’t, if I’m honest, given much thought to.
I am very much at the ‘trying to make it work’ stage of programming. Or rather, for the most part, I am at the ‘deciding what I want to design’ stage. I am working from the user side of things, for the most part: I know want thumbnails of individual records displayed in a grid so I can reorder information and drag things around, and the next step was to work out how such a thing might be implemented. The _actual implementation_ is still a fair way away, but I have a good idea of what I need to do.
Failing gracefully goes beyond that. (At this point in time I have no idea how much error handling OS X will provide or how the whole thign works – it honestly isn’t something I’ve looked into.) I think that asking yourself ‘what if it fails’ at every stage of the application might easily lead to paranoia – but on the other hand, when things go wrong, you’ll be able to at least display a useful message to the user.
The trick will be, I think, to anticipate high-level errors. You cannot possibly think of every way in which [open file] can fail (and a good number of them are listed in the article, some of which I hadn’t thought of), but you _can_ test whether your application was able to read the kind of information it expected, and put up an error otherwise.