Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Blew

Exceptions or return values?

This topic is 5405 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Depending on the situation, i''ve used exceptions and return values to report errors in C++ code. What''s the best practice in game programming? Personally, i think exceptions are much more organized since you can throw an object with error id, error string, etc. And you can throw diferent objects for diferent errors. Using return values you would probably need a static variable to store the error id. But i''ve read that exceptions are much slower (that''s kinda obvious) and that they shouldn''t be used on game programming (not that obvious to me). Maybe on speed critical code one shouldn''t use exceptions, but then again, maybe one shouldn''t even check for errors... Someone enlight me please.

Share this post


Link to post
Share on other sites
Advertisement
Well, like you said, for me, it depends on the situation. I mainly use exception when there is a fatal error that the application can''t proceed and must terminate immediately, such as graphics failure.

And I use return values when an error occurs but the application can still continue.

Share this post


Link to post
Share on other sites
Exceptions are supposed to be thrown under exceptional circumstances. IMO, the speed of exception handling should not be an issue because they should occur so rarely, or under such critical circumstances, that speed doesn''t really matter. They are not intended, and should not be used, as any sort of replacement for return values.

Share this post


Link to post
Share on other sites
I think the greatest benefit of using exceptions, apart from seperating error-handling code and being unignorable, is that you can return to using return values for their original purpose.

This simple line,

size_t Health = GameObjects.get("Soldier01")->getHealth();

would have to become a lot less readable if you used return values to communicate errors to the caller:

GameObject *pSoldier = GameObjects.get("Soldier01");
if(!pSoldier) {
ErrorStack.push("Unable to find Soldier01 in this map");
return E_FAIL;
}

size_t Health = pSoldier->getHealth();


There are other cases where this is useful:

MyClass::MyClass() :
m_SomeValue(getSomeValue()) {}

would become

MyClass::MyClass() {
if(!getSomeValue(m_SomeValue)) {
m_ErrorStack.push("getSomeValue() failed unexpectedly");
// Can''t return error code from constructor
// Has to complete construction of invalid object
// and trust the user to check the getError() Method
m_LastError = E_FAIL;
}
}


-Markus-

Share this post


Link to post
Share on other sites
quote:
Original post by Cygon
I think the greatest benefit of using exceptions, apart from seperating error-handling code and being unignorable, is that you can return to using return values for their original purpose.


That''s exactly why i like to use exceptions better. Your examples are great.

quote:
Original post by Miserable
Exceptions are supposed to be thrown under exceptional circumstances. IMO, the speed of exception handling should not be an issue because they should occur so rarely, or under such critical circumstances, that speed doesn''t really matter. They are not intended, and should not be used, as any sort of replacement for return values.


Hmmm, if i decide to use exceptions on my app/game then i will stick to exceptions. I wouldn''t use return codes in one fuction and exceptions on the next. If i''m coding some kind of reusable code, as a library or an engine i''m sure the guys who''d use it would be pissed at me if i didn''t stick to one of the methods.
So yes, they would be used as a replacement for return values, since they would do exactly the same thing: report errors.

For example, I could throw an exception when graphics fail to initialize, memory allocation fails, map/texture/whatever loading fails, the user tries an invalid movement, and so on.

So, basicaly, if i decide to use exceptions on a given code, i''d use them kinda like Java does. On the other way, if i chose to use return values, then i''d code things like the C run-time library. Is this nonsense?

Share this post


Link to post
Share on other sites
the thing is, not all error conditions are going to be critcal or exceptional and as you said in your first post, exceptions are slow.

The trick is to find the right balance between the two, something which will come with experiance and using the system.

As for your gfx library example, i''d be more concerned about an over user of exceptions rather than a mixing of exceptions and return codes

Share this post


Link to post
Share on other sites
quote:
Original post by Arild Fines
To say that exceptions should only be used for fatal errors is dogmatic and silly. If they were, we wouldn't have a catch statement.
why is that? Since when the exception is thrown the code would jump into the catch statement, I'd have this code that doesn't get executed which can misbehave the program. For example:

try
{
for( int i = 0; i < 100; ++i )
gameObjects[ i ].Update();
}
catch( Exception e )
{
e.Report();
}

If for some reason gameObjects[6] throws an exception (due to some simple error, i.e failure in pathfinding AI) in the loop, gameObjects[7]-gameObjects[99] wouldn't get updated. And depending on the Update() function, they might not even get drawn on the screen.

[edited by - alnite on February 29, 2004 7:03:00 PM]

Share this post


Link to post
Share on other sites
Fatal error means that the program cannot return to normal operation. The catch statement is used to help return the program to normal operation or to close gracefully therefore exceptions are not to be used in only for fatal errors.


Thanks Salsa!Colin Jeanne | Invader''s Realm
"I forgot I had the Scroll Lock key until a few weeks ago when some asshole program used it. It even used it right" - Conner McCloud

Share this post


Link to post
Share on other sites
the problem is, "fatal" is defined by the program at hand, so you cant say that "execptions are only for fatal problems" because in some cases the situation isnt fatal to the program.
In something i was coding recently i had to do some exception catching mainly for boost::lexical_cast<>() as sometimes it would fail to be able to give me an int from a string, this wasnt fatal to the program and it didnt really effect normal operation, in the majority, if not all cases, i set the value to 0 in the catch block and carried on, program maintians normal operation life is good.

So, it depends on the situation as to when and if you should use exception but the clue is really in the name for them ''exceptions''...

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!