"Unexpected error"... what's that? Lately I've been writing a lot of new code at work, and I've faced the question frequently: "Do I really need an exception handler HERE?? I just added a few around this part..." Yes, usually there is a need and it's a true need. Let me explain: if there is an exception in the program that didn't go through my exception handler (which logs the actual error message in this special case of a remote DB application that nobody is watching), a "refreshing" hit-and-miss operation will be carried out, possibly causing a domino effect creating a number of new bugs and logic faults just because I didn't spot the missing double quote or something similar that caused the original fault.
I'm guessing that the "unexpected errors" in the world largely go to the waste bin. I mean, they don't tell what went wrong to most of the developers, regardless of the fancy hex codes and address pointer values. (This hints that those messages don't tell anything to me, though I don't know if I'm amongst the "most of the developers" or not.)
Someone said back then that most of the computer code is used for checking/validating the (user) input. I think that is true. Especially when the "is used" is replaced by "should be used". But when you cannot really validate the input, write decent exception handlers! Simple as that. Either way, implementing the actual function may not be a big task, but making it fault tolerant, or even user-friendly that tells clearly what went wrong... that is a never-ending story ;)
No comments:
Post a Comment