Marco Tabini has taken a different tack on error handling in his latest post. He suggests that developers need to spend a little less time trying to prevent so many errors and a little more time handling the ones that do happen.

When an error occurs, the vast majority of the web-based application code that I see during my reviews performs the software equivalent of running around with its head cut off: the developer spends an inordinate amount of time and resources trying to make the software look like what was essentially a catastrophic failure was nothing more than a small temporary hiccup.

[...] In reality, by the time an error has occurred, there are only two possible outcomes: either you expected the error to occur, in which case you have already written code to handle the failure, or you didn't, in which case your main focus should be to use the error as a learning opportunity.

Marco suggests alternatives to this usual worry and hysteria - spend more time ensuring that (if something does fail) there won't be any more damage, let the IT team know as soon as you find the issue and testing before you fix (reproduce the error before you dig in to try to fix it).