Best way to handle errors (esp. in games)
-
I am currently writing a game in C++ using OpenGL and I wonder which is the best way to deal with errors, once they occur (especially in games). Note: I am currently using possibility 2, but I'm not really happy with it. 1. Exceptions - At first glance they seem to be the perfect for all kinds of errors, but I found out that exceptions can produce heck of a lot of overhead and extra time cost and IMO they're making the code ugly. 2. Return values - It's said that checking success using return values is deprecated since C++'s built-in exception handling. I can't share that opinion, but retrieving a return value and checking it doesn't seem to be an 'elegant' way of doing this and isn't beautiful as well (due to thousands of
ifand/orswitchstatements. 3. Return value + global error indicator - This one's really deprecated, even though I somehow liked the errno thingy in C :) So, what do you use/what would you use and what would you recommend for my needs? Thanks in advance. PS: Do I have some kind of natural aversion to exceptions or are they really not the greatest invention since sliced bread? -
I am currently writing a game in C++ using OpenGL and I wonder which is the best way to deal with errors, once they occur (especially in games). Note: I am currently using possibility 2, but I'm not really happy with it. 1. Exceptions - At first glance they seem to be the perfect for all kinds of errors, but I found out that exceptions can produce heck of a lot of overhead and extra time cost and IMO they're making the code ugly. 2. Return values - It's said that checking success using return values is deprecated since C++'s built-in exception handling. I can't share that opinion, but retrieving a return value and checking it doesn't seem to be an 'elegant' way of doing this and isn't beautiful as well (due to thousands of
ifand/orswitchstatements. 3. Return value + global error indicator - This one's really deprecated, even though I somehow liked the errno thingy in C :) So, what do you use/what would you use and what would you recommend for my needs? Thanks in advance. PS: Do I have some kind of natural aversion to exceptions or are they really not the greatest invention since sliced bread?I think in error handling, performance should not be of concern. So, the "I'm writing a game, everything must be fast!" argument doesn't work here. Errors should always be the exception! :) Exceptions really help you to write smaller code. When using return values, you have to check them every time. If you forget to do so, you might miss an error. So they are really prone to bugs! Exceptions on the other hand can't be simply ignored, and I think that's good.
Visit my project: Derivative Calculator
-
I am currently writing a game in C++ using OpenGL and I wonder which is the best way to deal with errors, once they occur (especially in games). Note: I am currently using possibility 2, but I'm not really happy with it. 1. Exceptions - At first glance they seem to be the perfect for all kinds of errors, but I found out that exceptions can produce heck of a lot of overhead and extra time cost and IMO they're making the code ugly. 2. Return values - It's said that checking success using return values is deprecated since C++'s built-in exception handling. I can't share that opinion, but retrieving a return value and checking it doesn't seem to be an 'elegant' way of doing this and isn't beautiful as well (due to thousands of
ifand/orswitchstatements. 3. Return value + global error indicator - This one's really deprecated, even though I somehow liked the errno thingy in C :) So, what do you use/what would you use and what would you recommend for my needs? Thanks in advance. PS: Do I have some kind of natural aversion to exceptions or are they really not the greatest invention since sliced bread?forkbomber wrote:
...but I found out that exceptions can produce heck of a lot of overhead and extra time cost...
See here.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
-
I am currently writing a game in C++ using OpenGL and I wonder which is the best way to deal with errors, once they occur (especially in games). Note: I am currently using possibility 2, but I'm not really happy with it. 1. Exceptions - At first glance they seem to be the perfect for all kinds of errors, but I found out that exceptions can produce heck of a lot of overhead and extra time cost and IMO they're making the code ugly. 2. Return values - It's said that checking success using return values is deprecated since C++'s built-in exception handling. I can't share that opinion, but retrieving a return value and checking it doesn't seem to be an 'elegant' way of doing this and isn't beautiful as well (due to thousands of
ifand/orswitchstatements. 3. Return value + global error indicator - This one's really deprecated, even though I somehow liked the errno thingy in C :) So, what do you use/what would you use and what would you recommend for my needs? Thanks in advance. PS: Do I have some kind of natural aversion to exceptions or are they really not the greatest invention since sliced bread?Use exceptions for errors you can't recover from e.g: - Wrong OpenGL version, throw an exception - No memory - runtime throws an exception for you - Can't find a critical game resource, a fall back texture, shader or something else that really must be there - Some muppet's deleted a delay loaded DLL - Steam doesn't initialise and you're using it for copy protection - You can't open any file to save the game - throw an exception Use return values for things you can recover from, e.g: - Network connection flakey - you don't want your game to crash 'cause your cheap hosting server in Borneo is offline due to Orang-utan attack - Can't find a game resource that you have a fallback for - Steam can't share a file, back off and try again - You can't open a save game file, back off and try again with a different name If you're code looks ugly you're not using exceptions for critical errors and you've got exception handlers all over the place. Ideally for yummy, perfect code you should only have exception handlers: - At the top level of your code - around main, WinMain or whatever for your platform - Around thread entry/exit functions - Around window procedures/GUI callbacks So basically: - Exceptions are for critical errors - Exception handlers only appear when your code is about to disapear UP the call stack into the OS, otherwise madness and the end of western civilisation will result. Exceptions being really expensive is a myth. See one of the previous posts for details, or hey, measure it yourself.
-
Use exceptions for errors you can't recover from e.g: - Wrong OpenGL version, throw an exception - No memory - runtime throws an exception for you - Can't find a critical game resource, a fall back texture, shader or something else that really must be there - Some muppet's deleted a delay loaded DLL - Steam doesn't initialise and you're using it for copy protection - You can't open any file to save the game - throw an exception Use return values for things you can recover from, e.g: - Network connection flakey - you don't want your game to crash 'cause your cheap hosting server in Borneo is offline due to Orang-utan attack - Can't find a game resource that you have a fallback for - Steam can't share a file, back off and try again - You can't open a save game file, back off and try again with a different name If you're code looks ugly you're not using exceptions for critical errors and you've got exception handlers all over the place. Ideally for yummy, perfect code you should only have exception handlers: - At the top level of your code - around main, WinMain or whatever for your platform - Around thread entry/exit functions - Around window procedures/GUI callbacks So basically: - Exceptions are for critical errors - Exception handlers only appear when your code is about to disapear UP the call stack into the OS, otherwise madness and the end of western civilisation will result. Exceptions being really expensive is a myth. See one of the previous posts for details, or hey, measure it yourself.
Hey there and thanks to everybody for clearing things up. I'm going to use exceptions now.
-
forkbomber wrote:
...but I found out that exceptions can produce heck of a lot of overhead and extra time cost...
See here.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
that sir is an *excellent* link to a great detail of information.
Charlie Gilley You're going to tell me what I want to know, or I'm going to beat you to death in your own house. "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
that sir is an *excellent* link to a great detail of information.
Charlie Gilley You're going to tell me what I want to know, or I'm going to beat you to death in your own house. "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Joe's articles usually are.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
-
I think in error handling, performance should not be of concern. So, the "I'm writing a game, everything must be fast!" argument doesn't work here. Errors should always be the exception! :) Exceptions really help you to write smaller code. When using return values, you have to check them every time. If you forget to do so, you might miss an error. So they are really prone to bugs! Exceptions on the other hand can't be simply ignored, and I think that's good.
Visit my project: Derivative Calculator
TomasRiker2 wrote:
Errors should always be the exception!
Well said! Can I quote you on this? :-D
-
I am currently writing a game in C++ using OpenGL and I wonder which is the best way to deal with errors, once they occur (especially in games). Note: I am currently using possibility 2, but I'm not really happy with it. 1. Exceptions - At first glance they seem to be the perfect for all kinds of errors, but I found out that exceptions can produce heck of a lot of overhead and extra time cost and IMO they're making the code ugly. 2. Return values - It's said that checking success using return values is deprecated since C++'s built-in exception handling. I can't share that opinion, but retrieving a return value and checking it doesn't seem to be an 'elegant' way of doing this and isn't beautiful as well (due to thousands of
ifand/orswitchstatements. 3. Return value + global error indicator - This one's really deprecated, even though I somehow liked the errno thingy in C :) So, what do you use/what would you use and what would you recommend for my needs? Thanks in advance. PS: Do I have some kind of natural aversion to exceptions or are they really not the greatest invention since sliced bread?Without directly referencing your enumeration, these are the things you should consider: 1. You can't avoid exceptions completely as some DLLs may throw them, so you at least need to be able to catch them 2. Exceptions provide a built-in mechanism to pass messages and an error identifier, and you can easily extend exception objects to hold additional data. 3. Exceptions will pass control to the level of the next higher try block in the call stack, without having to forward a return values up through several function calls. 4. You can't 'forget' to check for an exception like you can forget to check an error return: provided you catch all exceptions in your main function, you can at the very least issue a meaningful error message before having to exit the program. In fact, exceptions are the only way to 100% prevent a 'silent death' of your application, and will prevent most cases of 'hanging' (except for those caused by infinite loops, and then only those cases where you didn't think to check on preconditions and throw an exception if not met...) Note that the last point (being almost always able to catch an error before the app breaks down) may also allow you to recover sufficient status information for saving the game and resuming at that point! I would say that is a pretty strong point from the PoV of the gamer.