And by that no I don’t mean that YOU personally should fail. I’m of the same mind as my dad on that front. You should work your ass off to do the best job you know how to do. That doesn’t mean you’re perfect or that you expect perfection. There are lots of things in this world that I do not know how to do very well – but when given the opportunity I try to do the very best job I know how to and I try to learn how to do it better next time.
What I mean by the above is that your CODE should fail early often and loudly. I know some folks say “software should never fail” and thats a great goal to strive for but there are times and reasons why that is very close to impossible to prove without it being so ridiculously expensive that its just not practical for the vast majority of use cases.
And in those cases that you DO detect a failure, more than likely some exception, that you cannot handle or did not code for your code should bitch moan whine and grind to a halt immediately. Don’t try and recover from something you didn’t foresee. You may, by trying to recover from some unforeseen failure, actually cause more damage. If memory got corrupted and you try to recover you could wipe the hard drive or so something else much worse.
Personally I’m a fan of writing code in a way that it basically asserts preconditions at the beginning of the method and what inputs it expects. Some languages make this really easy to do – but you can do this in any language.
Range checks, format checks, nil checks and other checks as the first few lines of a method making sure things are the way your code expects make it easier to handle any issues that arise before you get far.
User inputs should be checked and sanitized at the point they are gathered. And if they are then your code should never get values for parameters that are unexpected (you did check ranges and such right ?????)
After that you code as defensively as you can and behave reasonably. But trying to recover from something that is a potentially fatal error (not just an out of bounds which you _should_ be able to handle in a reasonable fashion)
An unexpected runtime exception that is NOT one you anticipated SHOULD, IMHO, STOP your app right then and there and set things up in a way the end user CAN report it to you so you can fix it. It should not try to do anything else as you have NO assurance you CAN do anything else reasonable at that point.
Trying to continue on operation may well result in even more failures hat could do even more damage.
So write the best most well thought out code you can.
And when all the rest of the world and your environment is letting you down FAIL before you seriously break something else (like deleting a database or corrupting it)
And tell your user as much as you can WHY things failed.
And then fix it as correctly and quickly as you can