# Exception Handling

## Recommended Posts

Ahoy there, Im currently trying to figure exception handling out, particularly when to use them. I did a search on Gamedev for exception handling and found a forum which stated basically that they should be used in exceptional cases. But what exactly does that mean? This is my understanding so far: if you're coding a text editing program and use it to open a text document that is corrupt, you should not use an exception because opening a corrupt text document isnt going to (or shouldnt) bring the application down, so usual error handling should suffice. However, if you're creating a game and a critical library fails to load which would end up bringing the application down, you should use exception handling because it is a rather exceptional situation. Is this too simplistic? My main problem is that, I see exceptions as code that produce nasty error messages on the screen, whereas normal error handling (when done to avoid exceptions generated by third party code) can produce gentle error messages using the well known MessageBox. Once again, I think I may be missing the point, but I dont know. The other forum on the subject suggested a book called the pragmatic programmer, I havent gotten around to reading it yet, but do tend on reading it. In the mean time, does anybody have any suggestions or help they can offer? Thanks guys!

##### Share on other sites
Which language are you using exceptions in? This makes a big difference as to when it's appropriate to use them.
Quote:
 Original post by magnanimousnessMy main problem is that, I see exceptions as code that produce nasty error messages on the screen, whereas normal error handling (when done to avoid exceptions generated by third party code) can produce gentle error messages using the well known MessageBox.
This is what happens when you have an unhandled exception. That means an exception was thrown at some point, but there was no code anywhere to catch it.

e.g. Say when opening a new document, you call a "parse document" function, which can fail at any point if it finds the document is corrupt. If it fails (or any of it's sub-functions fail), a CorruptDocument exception will be thrown.
Somewhere higher up, perhaps in the function that initiated the loading process, there must be a try/catch block which will perform appropriate error handling in the case of a CorruptDocument exception... otherwise the exception will propagate all the way up the stack to the main function, become an unhandled exception and crash your program with a nasty dialog.

##### Share on other sites
An error is an error. Exception handling is what you do with the errors. Exception Handling should give you some more info.

##### Share on other sites
Quote:
 Original post by magnanimousnessif you're coding a text editing program and use it to open a text document that is corrupt, you should not use an exception because opening a corrupt text document isnt going to (or shouldnt) bring the application down, so usual error handling should suffice.

In general that's good advice, but there are other times when you can safely use exceptions. In your example, if the user has asked your program to open a file, they'll be expecting a short delay. That means you can probably afford to throw and catch an exception - it won't take enough extra time to make a discernible difference to the user.

##### Share on other sites
Quote:
 Original post by HodgmanWhich language are you using exceptions in? This makes a big difference as to when it's appropriate to use them.

The main languages I use are python, c# and c++.

But is there any hard and fast rule that states where error handling should be used and where exception handling should be used?

Quote:
 Original post by TheGroggyOneAn error is an error. Exception handling is what you do with the errors. Exception Handling should give you some more info.

I read that you shouldnt use exception handling for everything though?

##### Share on other sites
The way I see it, exceptions are basically "errors", and exception handling is basically the same as "error handling".

Compare (pseudo code):
void foo1 () throws SomeException {..   if (something_went_wrong) {      throw SomeException;   }..}

with:
void foo2 (Status& status) {..   if (something_went_wrong) {      status.error();   }..}

in the context:
void context {   // ex. 1   try {     foo1();   }   catch (SomeException) {     // take action   }   // ex. 2   Status s;   foo2 (s);   if (!s.error_flag()) {      // take action   }}

It's different ways of doing the same thing, i.e. handling exceptional stuff that occurs.

To answer your post: There is no saying that a component throwing an exception is equivalent to bringing the application down all together. It depends on how you choose to handle the exception(s). If you want to add error handling to your application (and you would want that), you have the choice of using exceptions to implement your handling.

##### Share on other sites
Everybody has a different opinion on the line between exceptions and "usual error handling".

As others have mentioned you seem to be under the impression that an exception always causes your program to blow up. This isn't true. You can catch exceptions and handle them gracefully. Your example of a corrupted document is actually one that I think would be an ideal candidate for exceptions. Probably the vast majority of time documents aren't going to be corrupt (sounds like an exceptional case) and determining that it's corrupt is probably relatively hard and involves lots of document parsing. Bubbling up error codes all over the place will just make all the code that's already hard even harder.

My rule of thumb is to default to using exceptions and set my debugger to always break on all exceptions. If I'm getting annoyed at how often it breaks than some path is overusing exceptions and should switch to error codes.

One reason why you might get confused is that people mix up two different kinds of exceptions. There are exceptions provided by the language (e.g. throw/try/catch in C++ or C#, raise/try/except in Python, etc.). And then there are what Windows calls "structured exceptions". Structured exceptions are what happens when your program crashes, tries to divide by zero (in C/C++), that sort of thing.

Generally speaking you shouldn't try to handle structured exceptions as they mean something has gone seriously wrong and the OS is raising the exception. On the other hand "language exceptions" are fine because you're the one deciding when to use them.

##### Share on other sites
If there were easy answers to this stuff, you would already have them. Sorry.