• Popular Now

• 12
• 14
• 13
• 10
• 11

Archived

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

The (un-?)popularity of try, throw and catch

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

Recommended Posts

I was just curious how many of the game programmers on this forum use C++-style exception handling (try-throw-catch) to check their errors, as opposed to more conventional error-checking devices (returning error codes, error members in classes, etc.). Does exception handling blend well into game programming? I notice that most functions that I see posted in this forum and the API forum do not have throw() lists on the declaration, so I couldn''t help wondering if try-throw-catch was unpopular to game programmers. I haven''t made the switch yet because I''m more accustomed to returning an error code, but I can see some of the benefits, such as fewer explicit error checks (it''s really annoying to have to draw pixels with "err = DrawPixel(x,y); if (err) return err" when you can just draw them all and catch all the exceptions in separate blocks. Are there any documents or examples on using exception handling in games?

Share on other sites
Dude, check out the past featured articles section under programming. I haven''t checked, but i swear i saw something with exception handling. It was an asrticle written a while ago. Exception handling in C++ i think it was. Check it out.

==============================
\\// live long and prosper; \||/ die short and rot.
==============================

Share on other sites
I like to use exceptions. However I never use throw lists because for one I don''t think VC really supports them and for two I think they''r a really dumb idea. In a complex app it''s very hard to be sure exactly what exceptions might get thrown in the current code let alone for the rest of time. So people end up deriving their entire exception heirarchy from a single class and list that class in the declartion which makes it pointless anyway.

I think people don''t use exceptions for several reasons. The first is that there is a perception that they slow down your code. I have yet to see any hard data that support this in the common case - when the excpetion is *not* thrown. Secondly, exceptions require a bit of up front disipline to use correctly. You have to make sure that all resources are allocated such that the will be autmatically freed when an exception happens. Thirdly once they get started people tend to want to use exceptions for non-exceptional changes in control flow. This bad practice *does* cause performance problems which then turns them off of exceptions again. Lastly, exceptions are relatively new. Cutting and pasting old code, then going through it and making it exception friendly takes more effort than not using exceptions at all.

-Mike

Share on other sites
quote:

However I never use throw lists because for one I don''t think VC really supports them and for two I think they''re a really dumb idea.

I don''t use throw lists, but it''s not because VC doesn''t support them (which it doesn''t). It''s because of what happens if the wrong kind of exception gets out, the default action is to terminate the program. Even if exceptions where checked at compile time (like they should be, just like const), it means you have to change lots of code that shoudn''t care about the exceptions. e.g.

void bar() throw(my_exception){	//some code that can throw}void foo() throw(my_exception){	bar();}void goo(){	try	{		foo();	}	catch(...)	{		//etc...	}}

Now if bar() decided it''s to also throw my_other_exception, you also need to change foo() and the whole point of exceptions is avoid the code in between the error and the handler needing to know about the error. In real life it''s pretty likely you''d have more functions this, which means even more work for something that really doesn''t matter.

quote:

So people end up deriving their entire exception heirarchy from a single class and list that class in the declartion which makes it pointless anyway

Unlike other classes, it''s a good idea to derive all your exceptions from the same class (e.g. std::exception). It makes it easier for you add new exceptions - most code doesn''t really care what was thrown, if they are catching it. (and even more functions shouldn''t need to catch anything, as long as you use std::auto_ptr and things like). and it''s nice to be able to do something like this:

int main(){	try	{		//rest of main	}	catch(std::exception e)	{		cerr << "Unhanded exception : " << e.what() << endl;	}	}

Share on other sites
The function exception specification ("throw()") is a performance hint to the compiler, similar to inline in purpose. You do not inline everything, and you do not add throw to the end of all your functions indicating what exceptions they must throw. The most common usage of throw will probably be:

inline some_fast_simple_function_that_doesn''t_call_anything_else() throw(){ ::x += 2; } // whatever...

C++ compilers don''t optimize as well as they should. Either: 1) the compiler writers are lazy, or 2) (much more likely) the language requires lots of time/energy to optimize. C++ can be very low-level, doing bit-manipulation and such, and it can be very high-level using classes, virtual functions, etc. Providing the function exception specification syntax may help programmers optimize their code (and thus make wider use of exceptions!) while still programming on poorly optimizing compilers.

I heard it explained that functions that throw exceptions can be slower (every little bit may count, as in a pixel-plotting function ), but of course you should check that out for yourself. I would like to understand why myself...

Happy Coding!

- null_pointer
Sabre Multimedia

Share on other sites
2.5 cents ->
I use exceptions extensively in my DirectX-using Windows98-hosted gambling machines, and the only time I use any form of exception specification is on the member functions for the exception classes themselves, and on certain functions that cannot throw exceptions either due to being simple and self contained, or due to catching all exceptions and recovering from any situation (not too common .

I do not know what form of performance impact I pay for using exception as I have never had a version of the program running without them.

Share on other sites
I don''t use try/catch/throw because it''s only good for really bad errors!!!

Well, you could use it for simple "non terminal" errors. The problem is that you have to use auto_ptr stuff to prevent memory leaks!
If an exception get''s thrown out of nowhere, a lot of shit has to be freed and destroyed and uninitiated and de-allocated and...

Share on other sites
Sorry if this makes anybody mad as this is a question not an opinion.

lots of questions

Do all exception terminate the program?, or is that just the examples that i read.
(wrote the check(int) method as practice)
(any mistakes? )
(made in Java as well, not a C question )

say i have a "pick a number between 1-10" program
Main
calls a method "getinput" that trys to check the int by calling
check(numberentered) and it also catches the BadintException

boolean check(int i)
{
if (i != 0) {
if (i < 11) { return true;}
else { throw new BadintException(i); } // number is bigger then 11 "big no no"
}
else { throw new BadintException(i); }// number is 0 "big no no"
}

relevant to the program:
what is the best way to make the user pick another number?
I can only think of two solutions/questions 1.call getinput again from within the catch block.(is this bad programming? as in get stuck in a loop)

2.forget the exceptions and just have getinput loop until check(int) returns true? btw. what is the best way to loop in this scenario?

is there a way a method can check to see if the variable x has been made/declared?
like:

if (x != null) { ++x;}
else {int x = 0;}

if (x != null) {
if (x != 10){
"call itself again"} //tehehe
}
else {
exit somehow(doens't matter to me)}

now can this method call itself and expect x to be 1 (cause the first call didn't return so x should still be declared right? )

will a compiletime or runtime( i expect compiletime error)
happen when this method is first called? because x isn't declared and can't be referenced (as in hasn't even been set to null).
is there another operator(?) i can use to see if a variable has been declared???

even if it is allowed, is it bad coding/practice/concept?

anyhelp is of course appreciated.

Phew!...Thanks.

Edited by - CodyVa on September 2, 2000 4:16:57 AM

Edited by - CodyVa on September 2, 2000 4:22:07 AM

Share on other sites
try-throw-catch isn't for dealing with your own errors, its for dealing with run-time errors that will end up killing your program. It is a waste of time to use them for normal errors that you might expect e.g. improper value entered because error codes are quicker and better.

Basically, try-throw-catch is just used to catch run-time errors:
try{ //this is saying "see if this works"}throw{ //this is saying "throw this exception if it doesn't work"{catch { /*instead of having a message come up about how your programs gonna die now, you can catch the error and recover\terminate gracefully. */}

If its just normal errors you are after this will do:
void CheckForError(int ErrorIndex){ if (ErrorIndex < 1 || ErrorIndex > 25) { ValidateError(); }}void ValidateError(){ Number = LastNumber; /*say you backed up number each time it changed*/}

etc. etc. You get the point

In the game industry I'm not sure how many people actually use it. I suspect it would have performance implications but I'm not sure on that.

Personally, I steer clear of them mostly, but I have been known to 'try' it on a few times because it can come in very handy in the right situations. Its just one more tool in the toolbox and that can't be a bad thing

Edited by - lucasdg on September 2, 2000 5:05:51 AM