# I hate error handling

I will admit that code with no error handling is wonderful and clean and easy to read....but its also a nightmare to maintain and use.

Often error handling code can be streamlined into a single function call. Consider the following c++ (written on the fly, may not compile ;) )
Code:
void ErrorBox(char* message, bool instruction)
{
MessageBox(NULL, NULL, &message, MB_OK);//Print error message box
if(instruction)//Quit program if true is passed, else continue
QuitProgram();
}

void MyFunction()
{
...
if(somethingsWentWrong) ErrorBox('File Not Found', true);   //Bail the app
}
(while i usualy hate a state check and action on one line, if its a commonly used one i feel its reasonable. ;) )

furthermore, i think error checking helps eliminate problems in debugging. if you have a 3d model that isn't being textured properly and you know that a texture has been loaded into memory, you can focus your attention to the other reasons that its not being textured.

chroot
Staff Emeritus
Gold Member
0rthodontist said:
Why should a programmer have to remember to put shorter, exception-free code in a comment? It would feel like busywork, and nobody's going to do that.
And having to add obvious decoration to a function prototype to say that it consumes input is busywork, and no one's going to do that either. Apparently, what most programmers would judge a needless burden, you would consider an incredibly important language feature. Potato, po-tah-to, yes?

It is not absolutely necessary to check the dates, because the worst that will happen is that the server (the one that's running this code) will spend an extra couple seconds writing stuff to disk that it already has.
I don't have the rest of the code for this program (whatever it is), but, by the looks of it, it'll probably list two different "versions" of the same RSS feed, with the same timestamp. It'll confuse the heck out of the user. Besides, if you ever decided to re-use this module for some other purpose, you (or your coworkers) will be very happy that you spent a few miniscule lines of code to compae the timestamp and make sure that the new version really is different from the previous, and didn't just decide to rely upon the often poorly-implemented HTTP RFC.

Assumptions -- like whether or not the user of this module is overwriting existing data, or is making a new list entry for every new version -- are the worst kind of evil in computer programming.

I certainly object to calling me a "novice" programmer. I'm not a novice programmer. Also, I certainly never suggested that the error handling should be in "some other file." It should be separate, but near.
I'm sorry, but the suggestion that programmers should break code locality in favor of some kind of aesthetic "code attractiveness" is a novice suggestion. In the real world, people don't care much about whether a function is a tidy one-liner or a half-page with a bunch of well-written error-handling; they care about whether or not it works, is re-usable, and is easy to read and maintain. No one's judging your code by its brevity in the real world. Separating error handling -- even just putting it into another area of the same file -- is by just about every criterion an awful idea.

- Warren

Apparently, what most programmers would judge a needless burden, you would consider an incredibly important language feature. Potato, po-tah-to, yes?
Brilliant! I'll have to remember that one.

Pretty much everything has been said by now. If I were to continue on with this "debate" any longer, we'd just keep seeing repeats of everyone's arguments.

This is going nowhere. I've said what I've had to say.

Last edited:
Haha, funny.

chroot said:
And having to add obvious decoration to a function prototype to say that it consumes input is busywork, and no one's going to do that either. Apparently, what most programmers would judge a needless burden, you would consider an incredibly important language feature. Potato, po-tah-to, yes?
Have you ever seen any programmer make use of this commenting style you are describing? If you're referring to the takes/alters syntax from another thread, I made it extremely clear that it would need to be automatically generated, and that in fact that was part of the point, so that it would provide documentation that a programmer might not have created on his own.

No time right now to reply to the rest.

chroot
Staff Emeritus
Gold Member
0rthodontist said:
Have you ever seen any programmer make use of this commenting style you are describing? If you're referring to the takes/alters syntax from another thread, I made it extremely clear that it would need to be automatically generated, and that in fact that was part of the point, so that it would provide documentation that a programmer might not have created on his own.
You're the one claiming that this coding style with "separated" error handling is superior to simply having the error-handling intermingled with the code it protects -- not me. I have never seen anyone besides you argue that this would be a good idea, so no, I have never seen anyone else do it.

- Warren