About try and catch performance.

This is a discussion on About try and catch performance. within the C++ Programming forums, part of the General Programming Boards category; Is it true that Try... catch.. affects runtime performance? Most of my friends told me that it is slow and ...

That said, in practice most compilers implement exceptions through `setjmp'/`longjmp' or similar. This exception model has some overhead whether you use exceptions or not.

Now that that is out of the way, I challenge you to do what exceptions do for C++ without any cost.

And now, exceptions should be used exactly when they should be used and at no other times. You fail if you use anything other than exceptions when you need exceptions. You fail if you use exceptions as "return codes". You fail if you `catch' only to `throw;'. You can use exceptions wrong in a lot of ways. That doesn't make exceptions slow. It makes you a lousy programmer.

The C++ exception mechanism was designed with "you don't pay for what you don't use" in mind.

In terms of performance, yes. But exceptions can have a significant impact on code size. I've seen code shrink by more than half when exception tables were turned off. Obviously, you cannot do that in code that actually throws exceptions.

Exceptions should not be used most of the time: they should only be used for exceptional cases. That is to say, when an exception happens, that should mean that there's something wrong, and therefore you don't care too much about performance anymore. So generally, exceptions are implemented such that throwing and catching an exception is indeed slow, but not throwing an exception is fast.

But exceptions are a good mechanism for dealing with those exceptional errors. When some resource becomes unavailable for instance. It simplifies your logic, and separates out the special case handling from the normal code. This can be a speedup, because you don't need logic at intermediate levels do check if an exception occurred. You only need logic to throw the exception, and to catch it were something can be done to handle it.

Actually there are times when as previously stated do have a good use for try and catch(...) code blocks.

I will refer to a class I posted here a while back it does use the try and catch(...) blocks it is even for a game now that being said I will explain why in this case at least it doesn't destroy performance. Generally when a dialogue is open there is nothing going on in the background - that being said try to print with given font if we can't use a default font so the program does not crash out.

I do believe there are implementaions when try catch() blocks are acceptable maybe not for every block of code you write, but it does add stability - which is a very big issue to many programs. Don't over use it and use it on small code blocks to limit how much code must be rerun. It is a tool to use and when you run into resources that can be beyond your control such as external files it can default to a safe setting to allow the program to keep running.Dialogue class code for RPG

That said, in practice most compilers implement exceptions through `setjmp'/`longjmp' or similar.

Outdated information.

Nowadays, practically all compilers on modern platforms use the static table approach, also called zero-cost exceptions, which only incurs a runtime penalty if an exception is actually thrown. This includes GCC on just about all platforms (even Windows in newer versions), and Microsoft's compiler on x64 Windows. 32-bit Windows still uses the old way.

Nowadays, practically all compilers on modern platforms use the static table approach, also called zero-cost exceptions, which only incurs a runtime penalty if an exception is actually thrown. This includes GCC on just about all platforms (even Windows in newer versions), and Microsoft's compiler on x64 Windows. 32-bit Windows still uses the old way.

In addition to this, if you handle errors by if's and return's, it has a lot of overhead as well for every conditional statement and return. It might even be slower than throwing.

In C++, I have a current project right now that uses Ogre3D as their graphics renderer and I noticed that they use try.. catch most of the time. My current small 3D graphics engine has no try and catch on it. That's why I'm wondering if I should really make it just throw exception instead of the if..else statement or am I just lost. lol

So, should I use try... catch? or try not to use it? Well, may I ask... do you use it?

So, should I use try... catch? or try not to use it? Well, may I ask... do you use it?

You should use exceptions if the situation calls for it.

I use exceptions everywhere they are practicable.

Instead of using exceptions to signal every unusual occurrence in your game, consider using return codes for most unusual occurrences and exceptions for cases that you can't recover from locally (say from within the primary "game loop"). One situation might be the loss of a packet versus the loss of the internet connection entirely. You could potentially recover locally from the lost packet. You should probably abort the game for the lost internet connection and only provide a message to the user as part of the caught exception.

Nowadays, practically all compilers [...] if an exception is actually thrown.

This is simply wrong unless you want to call a small percentage of compilers in the wild "practically all".

*shrug*

If you don't want to consider all the platforms GCC doesn't support, platforms GCC doesn't support anymore, platforms where GCC must be built with SJLJ exceptions, manufacturer provided compilers for a lot of embedded devices, most compilers for 32bit Windows compilers, and all small and embedded compilers I know of you should go for it.

Or even if you just want to call development on 32bit Windows "outdated" you should go for it.

I live here where only two (both GCC) of the two dozen compilers I have installed supports a table driven exception mechanism.