Exception Handling
Author
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!
Which language are you using exceptions in? This makes a big difference as to when it's appropriate to use them.
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.
Quote:Original post by magnanimousnessThis 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.
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.
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.
An error is an error. Exception handling is what you do with the errors. Exception Handling should give you some more info.
Quote:Original post by magnanimousness
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.
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.
Author
Quote:Original post by Hodgman
Which 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 TheGroggyOne
An 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?
The way I see it, exceptions are basically "errors", and exception handling is basically the same as "error handling".
Compare (pseudo code):
with:
in the context:
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.
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
