is Exception Handling widely used in commercial games programming?
Author
we know that Exception Handling is a very important feature of C++
but i've read some free & open source games on the net
hardly any Exception Handling code used in those games
so i was just wondering if it is necessary to learn Exception Handling
and i want to know is Exception Handling widely used in commercial games programming?
It's a good idea to learn it regardless of wether it's used a lot. It's better to know how to do something and not do it than to need to do it and not know how.
Exception handling is, good, bad, and ugly. It greatly simplifies and reduces your source code if your app is based on classes. It's not extremely beneficial if your app isn't. But there's always a downside. For functions that can throw exceptions, the compiler has to add implicit catch blocks EVERYWHERE. This leads to massive code bloat (and the things I've tested it on weren't even as complex as commercial projects).
EDIT: Oh yeah, and there's another major downside: exceptions are SLOW. I did some benchmarking a while back, and clocked almost 0.1 ms to get from the throw to the catch. Do NOT throw exceptions for errors that are moderately common, or you can kiss any kind of decent performance out the window. Exceptions are meant to be just that: exceptional cases that almost never happen.
EDIT: Oh yeah, and there's another major downside: exceptions are SLOW. I did some benchmarking a while back, and clocked almost 0.1 ms to get from the throw to the catch. Do NOT throw exceptions for errors that are moderately common, or you can kiss any kind of decent performance out the window. Exceptions are meant to be just that: exceptional cases that almost never happen.
Exceptions are an important tool to have (weather you use them or not) for complicated software engineering projects.
In my coding, I have found instances where exceptions are just about the only way of doing things (without a 10-fold increase in code size).
As was said before - don't do what Java does and use exceptions for absolutly everything, and very much avoid it for "normal" program flow. They are not exactly fast. However it's probably better to use exceptions in most "error" situations than to have a whole bunch of conditional jumps (for "catching" bad return codes and cleaning up).
When you don't have to check return codes and provide explicit cleanup, you'll have less overall code, and less repeditive code, which is a very good thing.
Basically, if you chose to never use exceptions, then you are chosing a posibility that your software will be poorly engineered and bug-prone and less extensible and so on (all these things that come with poor engineering).
Just make sure you know how to use them properly, and you're aware of the way they clean up stack objects and not heap objects (things that are new'd and delete'd), etc. If you know how to use them properly, you'll use them in the right situations and have better, faster programs.
The reason they arn't used in games often - probably because the developers are "silly", or they don't think of writing the game as an excercise in software engineering (and thus end up with a less flexible, buggier, less reusable program).
In my coding, I have found instances where exceptions are just about the only way of doing things (without a 10-fold increase in code size).
As was said before - don't do what Java does and use exceptions for absolutly everything, and very much avoid it for "normal" program flow. They are not exactly fast. However it's probably better to use exceptions in most "error" situations than to have a whole bunch of conditional jumps (for "catching" bad return codes and cleaning up).
When you don't have to check return codes and provide explicit cleanup, you'll have less overall code, and less repeditive code, which is a very good thing.
Basically, if you chose to never use exceptions, then you are chosing a posibility that your software will be poorly engineered and bug-prone and less extensible and so on (all these things that come with poor engineering).
Just make sure you know how to use them properly, and you're aware of the way they clean up stack objects and not heap objects (things that are new'd and delete'd), etc. If you know how to use them properly, you'll use them in the right situations and have better, faster programs.
The reason they arn't used in games often - probably because the developers are "silly", or they don't think of writing the game as an excercise in software engineering (and thus end up with a less flexible, buggier, less reusable program).
This is actually a current topic on the Software Engineering - Gamedev mailing list. See http://lists.midnightryder.com/pipermail/sweng-gamedev-midnightryder.com/ for the archive. The thread started May 12.
The general consensus is the answer is no, with one specific exception. (pun intended).
Good exception-safe code is not easy. That's a big reason to avoid it up front.
Exception handling generally introduces overhead (either time and memory at runtime, or space in the application), which can be a problem when you're counting CPU cycles and every byte of memory.
In consoles, there is no OS to fall back to. You handle everything yourself. If something fails, you should provide a reasonable alternative, even if the alternative is an ugly solution. That means if a disk read fails, your code should retry it a few times, then find some way of showing an error message, rather than just throwing and causing the app to crash. The message should give the user the chance to remove the disc, clean it, and put it back. Every error should be handled locally, and return an error value if there was a problem.
On the desktop, basically the same thing is true. This is entertainment, not a productivity software. If you can't load an asset, just pick some reasonable alternative and log the error. For a texture or model, have a generic "THIS IS A PROBLEM" asset that can be used, such as a big orange texture or a model of the word "ASSET NOT FOUND", sounds could be an annoying audio message, and so on. In the release assets, replace them with non-annoying elements.
The general answer is "Do something reasonable, record it in a log file, and return an error."
Pretty much the only place you should use exceptions are situations where you are escaping from a fairly large logic block. The code should be written by somebody who understands exception-safe code, and it should be carefully reviewed. No exceptions should propogate back to the caller from a library or engine function call, since you can't count on other programmers writing exception-safe code.
Hope that helps.
frob
The general consensus is the answer is no, with one specific exception. (pun intended).
Good exception-safe code is not easy. That's a big reason to avoid it up front.
Exception handling generally introduces overhead (either time and memory at runtime, or space in the application), which can be a problem when you're counting CPU cycles and every byte of memory.
In consoles, there is no OS to fall back to. You handle everything yourself. If something fails, you should provide a reasonable alternative, even if the alternative is an ugly solution. That means if a disk read fails, your code should retry it a few times, then find some way of showing an error message, rather than just throwing and causing the app to crash. The message should give the user the chance to remove the disc, clean it, and put it back. Every error should be handled locally, and return an error value if there was a problem.
On the desktop, basically the same thing is true. This is entertainment, not a productivity software. If you can't load an asset, just pick some reasonable alternative and log the error. For a texture or model, have a generic "THIS IS A PROBLEM" asset that can be used, such as a big orange texture or a model of the word "ASSET NOT FOUND", sounds could be an annoying audio message, and so on. In the release assets, replace them with non-annoying elements.
The general answer is "Do something reasonable, record it in a log file, and return an error."
Pretty much the only place you should use exceptions are situations where you are escaping from a fairly large logic block. The code should be written by somebody who understands exception-safe code, and it should be carefully reviewed. No exceptions should propogate back to the caller from a library or engine function call, since you can't count on other programmers writing exception-safe code.
Hope that helps.
frob
I think it's becoming more common on the PC, I'm pretty sure games such as Unreal & Dungeon Siege have used them. On consoles I would not be surprised if exceptions are typically disabled.
There are serious problems with current exception models that make them tremendous amounts of work to get right, yet they fail to provide adequate debugging information and there's no integrated recovery mechanism. You lose the stack so you can't inspect variable states (C++ won't even build a function call trace automatically, and it's hard to automate it without using the __FUNC__ C99 feature). You also have to swallow an exception and turn it into an error code in order to support a retry.
It's hard to avoid exceptions in standard C++, you can only give-up and not bother trying to make the program exception safe. You can disable exceptions with some (most?) compilers, but then you can't use much of the standard library (and new can still return 0).
There are serious problems with current exception models that make them tremendous amounts of work to get right, yet they fail to provide adequate debugging information and there's no integrated recovery mechanism. You lose the stack so you can't inspect variable states (C++ won't even build a function call trace automatically, and it's hard to automate it without using the __FUNC__ C99 feature). You also have to swallow an exception and turn it into an error code in order to support a retry.
It's hard to avoid exceptions in standard C++, you can only give-up and not bother trying to make the program exception safe. You can disable exceptions with some (most?) compilers, but then you can't use much of the standard library (and new can still return 0).
I don't get it - what is so hard about exceptions and why are they "hard to get right"??
The unreal engine from epic games use exceptions. If you look at the old code you can see a lot of members written in this way:
it is used also for logging and debugging cause unguard is #defined in other way if the debug flag is on. They make something like gLog->log(blah). This method is very good for me and I use it as well. This method is used by unreal developer for adding safety and clarity cause if the engine raise an error exception you can see from the crash dialog the stack unwinding, something like: Engine::WinMain::MessageBump::Core::Blah. It's professional and very good for error reporting. If I remember well I've read on Stroustrup book that the simple try catch must not add any kind of code overhead so you can use it without warning (notice the "must not"). If catching an exception is very slow this doesn't matter cause, as the name say, an exception is an exceptional event. When one is raised you can try to manage it and restore the internal data of the program, if not you must only gracefully end all.
#define guard(func) {static const TCHAR __FUNC_NAME__[]=TEXT(#func); try{#define unguard }catch(TCHAR*Err){throw Err;}catch(...){appUnwindf(TEXT("%s"),__FUNC_NAME__); throw;}void foo::bar(){guard(foo::bar) //some codeunguard}it is used also for logging and debugging cause unguard is #defined in other way if the debug flag is on. They make something like gLog->log(blah). This method is very good for me and I use it as well. This method is used by unreal developer for adding safety and clarity cause if the engine raise an error exception you can see from the crash dialog the stack unwinding, something like: Engine::WinMain::MessageBump::Core::Blah. It's professional and very good for error reporting. If I remember well I've read on Stroustrup book that the simple try catch must not add any kind of code overhead so you can use it without warning (notice the "must not"). If catching an exception is very slow this doesn't matter cause, as the name say, an exception is an exceptional event. When one is raised you can try to manage it and restore the internal data of the program, if not you must only gracefully end all.
Quote:Original post by frob
This is actually a current topic on the Software Engineering - Gamedev mailing list. See http://lists.midnightryder.com/pipermail/sweng-gamedev-midnightryder.com/ for the archive. The thread started May 12.
Holy crap. I'm reading that and I'm thinking:
"What the hell - are people thinking that exceptions are only used for this..."
int main(){ try { the_whole_program(); } catch(...) { print("something bad happened"); }}There are places other than "critical failure" that exceptions are good to use!
Heck - if that is all people are using exceptions for - why not just call abort().
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
