Hi all, I have been looking at exceptions recently and deciding whether to add them to my code. I read the two recent articles here on gamedev and both methods described a drop in performance on methods that throw and catch exceptions and possibly a general drop in performance everywhere. What I don''t understand is why. What I want from a throw statement is a way to return from a method without actually returning the right type for that method. And then to keep on throwing until someone catches the right type. As far as I''m concerned that should mean a hidden local variable in the method for each type it throws, that points to the relavent catch block. So when a method calls a method that throws a certain type it sets the local variable in the called method to either its catch block or a catch block on up the tree (whose address is stored in *its* local variable for that type). When a method throws a certain type it just jumps to the address contained in the associated local variable. So my questions are: 1) Do the other methods of exception handling do this anyway or something even better? 2) If not, is there any exceptions-lite syntax that does something like this? 3) If not, does anyone want to write me a VC++ add-in that does? 4) Do I just like the sound of my own (virtual) voice? Congratulations to anyone who made it this far and thanks in advance for your comments, ro

I use C++ exceptions all the time.
The people that say that they are slow are all ignorant or liars.
They assume that you will always ''throw'' instead of ''return''.
That''s bullshit.
You only ''throw'' when an unexpected error occurs.
Because unexpected errors should rarely occur you gain a performance gain for not using the stack to store return values.
Entering and leaving a try-blocks also produces very little overhead. The only time when C++ exceptions have worse performance is when an exception occurs. But since your app will likely exit anyway, nobody will notice those few CPU cycles.

Pseudo assembler:

; ------------------; Without exceptions; ------------------; if(function() == errorcode) Msgbox("YOU ARE ON YOUR WAY TO DESTRUCTION MAKE YOUR TIME");PUSH ARGUMENTSCALL FUNCTION; in functionPOP ARGUMENTSPUSH RETURNVALRETPOP RETURNVALCMP RETURNVAL, ERRORCODEJNZ PRODUCEERROR; ------------------; With exceptions; ------------------; function()PUSH ARGUMENTSCALL FUNCTIONPOP ARGUMENTS; in functionRET

---

ALL YOUR BASE ARE BELONG TO US
INTEL INSIDE: The worlds most widely used warning label.

The February issue of C/C++ Users Journal has a whole article about writing your own exception routines in C. That is applicable in C++ as well. You might want to go to your newstands to see if the Mag is still there.

First, there is no practical reason why using exception handling should degreade performance, though in application it often does (slightly). However you have to balance this against the reams of error recovery code you''d have to include otherwise.

1) exception handling is for exceptional situations, not flow control. think deeply on this

2) exceptions allow you to logically group error handling routines in central locations instead of using macros or scattering stuff all over your code

3) the benefit gaines from exception handling far outweighs its potential performance issues (as I said, they''re small... basically, there is a cost associated with entering a try block... so don''t go absolutely nuts with your granularity)

4) only one exception can be handled at a time -- if you throw a second while one is floating about the program will terminate. the most important consideration here is that you should never throw an exception out of a class destructor (unless you can *gurantee* that there will *never* be another exception floating about if you do so... which is generally not possible)

Exceptions are one of the greatest things aobut C++. Used properly, they can make your code more robust, streamlined, and stable.

To get a good understanding of how exceptions can affect performance you need to acutally look at the code your compiler generates.

For MSVC 6, on x86 you''ll see that there is some overhead on function entry to setup some stuff, then there is a store to a stack location before every call to a constructor or destructor for stack based variables that have destructors.

This isn''t the only way to do it and your milage may vary with different compilers, different versions of the same compiler, or the same version of the compiler for different processors and OS''s.

Whether all this is significant or not depends on the situation. Don''t jump to conclusions and throw away a perfectly good tool.

quote:

---

1) exception handling is for exceptional situations, not flow control. think deeply on this

---

(It bears repeating)

-Mike

I'll only dare touch my own specialty here.

C++ EH is a standard. It's the basis of popular EH mechanisms (but not the first, I'm sure).

SEH is an OS-specific technology. I happen to believe that it is more flexible, though a bit harder to learn, and that it can be used without ANY loss to performance, which means that it can be used to raise exceptions in NORMAL conditions.
I will say to you that you should not throw away EH unless you deem it necessary. What do you think your program needs? Not one of us can tell you for certain. Only the people who know your code and design inside out can.

-Vadim Kokielov

Edited by - GayleSaver on February 21, 2001 5:26:47 PM

Help, I''m now a mite confused...I thought that if I setup an excpetion handler in my program I just taked over from the standard Windows exception handler therefore there can not be a loss of performance (until my handler gets executed anyhow)

Nick B

quote:

---

Original post by rowbot

1) Do the other methods of exception handling do this anyway or something even better?

---

I think it''s a bit more than just a return address you have to keep track off. You need to know which objects have to be destructed when an exception occurs. There are probably other things like accessing the thread information block. ( FS register. I think windows SEH does it like that )

Your exception should not be thrown on the same stack too. I believe VC++ uses a seperate stack to throw the exception object. If you were to use the default stack, what would happen if you encountered a blown stack??

There is always a loss of performance by enabling exceptions for the object lifetime tracking. Nothing is free. Note, You do not take over windows exception handler if you setup your own exception handler (unless you used Win32 _set_se_translator )

Hardware exceptions are platform specific. What C++ std defines are only software exceptions.

---
There is always a loss of performance by enabling exceptions for the object lifetime tracking. Nothing is free. Note, You do not take over windows exception handler if you setup your own exception handler (unless you used Win32 _set_se_translator )
---

The loss of performance is minimal in SEH, and regardless of the circumstances it is greater in C++ EH due to special SEH filter code. And what do you mean by, " you don''t take over the Windows EH"?

quote:

---

Your exception should not be thrown on the same stack too. I believe VC++ uses a seperate stack to throw the exception object. If you were to use the default stack, what would happen if you encountered a blown stack??

---

Last time I looked, VC used the same stack. A throw (or RaiseException) essentially called some goo inside of the C++ (and Win32) runtime which then calls your filter funtion with stuff suitably whacked so that the filter function can see local variables. If the handler gets executed then everything is unwound and it jumps to the handler.

All this might not be immediately apparent in a stack backtrace but you can see if you compare esp''s and/or trace stuff by hand.

You can handle stack overflows because you get the exception before you''re actually out of stack. The exception happens when the final page of the stack is touched, not when you''re out completely.

-Mike