Quite a while back, I asked a friend if he thought "handling" an error by ignoring it, if you explicitly knew the error thrown could reasonably be ignored, was a proper sort of error handling. The answer, against my best programming instincts, was that he believed it was.

Now I've started wonder if not capturing errors where, if the code is written the way it should be, should never happen is legitimate. Again, my programming instincts say, "Absolutely not. There's always the proverbial horn of a rabbit, isn't there?" But isn't not capturing the same as ignoring, except in this case you "know" there's not going to be anything to ignore?

That said, and along those lines, I have taken to playing "all-powerful, overly confident programmer" a few times recently and have left error handling out for "the time being" in places where I just know it'll never happen. "Try and bust me on it," is a bad attitude to have when you're coding, even if there is a deadline. Oh well.

[Please note that, before I blog my way out of a job, I'm putting the finishing touches on an app that I'm going to leave to someone else in a few weeks. The idea here is that I'm going to have all the functionality there, and let the next fellow clean up after me. Though certainly that's not the most fun position for him, it is the best way to ensure that, no matter what happens down the line, the application will be a success.]