Quote:Original post by SunTzu
Sigh.
I won't try to speak for Bregma, but I believe the relevant metric here is
extra overhead, and your article only mentions
total overhead. To evaluate the
extra overhead of exception handling, you consider the total overhead of exception handling
and substract the total overhead of handling errors through return codes. Because, well, we're comparing two methods here, not comparing exception handling to the absence of any handling at all (where we already know that exception handling is slower).
So, let's consider a typical example:
// Exception handling method: // We call the function and store the result. If an exception is triggered, // we let it propagate up the call tree.int number = computation();// Return code method:// We call the function, check that the return code is correct. If it isn't, we// propagate up the call tree.int number;if (computation(number)){ return ERROR;}
I have voluntarily removed the cleanup code from both examples, since it will be fairly similar. I have also considered "number" to be an integer. In the case of a class, it would have been trickier (a design problem if the class has no default constructor) and would have caused optimization problems in the second case because of the redundant initialization. Note that I've also considered the average case where an exception will propagate up the call stack through several functions before reaching the corresponding catch: in an average program, the number of try blocks is much smaller than the number of function calls, so the per-function overhead of try block breadcrumb laying is negligible.
So, the first call has three push and five mov in addition to the standard function call, which is the expected overhead for exceptions. On the second call, we have at least one compare, one jump and one additional argument. So, how do the two compare?
A possible counter-argument is the fact that error handling does not span over the entire project. It error handling only occurs in a small part of your project, then it is clear that said portion is cleanly separated from the rest of the project. You may then gain from delegating that project portion to a library compiled with exceptions enabled, and the rest of the project to one or more libraries compiled with exceptions disabled, both on the performance aspect, and on the design aspect.
