Okay, so, a pretty simple test case is our friend, recursive Fibonacci. It's a pretty simple algorithm which would be pretty straightforward at demonstrating the issues. So, here are two versions, using checked trivial error returns and using exceptions. (The error condition in this case is whether the operation overflowed.) Both of them use the same mechanism for determining how large the stack has grown, and the error checking version is based on how it works in real code that's based on error checking.

(Note: I realize that the stack value isn't going to be exactly precise in terms of how much is used, but it is precise in showing how much it grows based on the depth of the call tree. That's all I care about here.)

(Also, to stave off any criticisms about the error-checking version, while yes, this could have used 0 to indicate error, that's meaningless in the context of most applications; 0 could be a valid result value. In real applications, you end up always using the errorType function(input, input, input, output&) method if you want to keep things consistent and sane.)

Code size

I compiled both versions with gcc-g++ 4.3.2 and stripped the executables. The error-return version weighs in at 5720 bytes, while the exception version is 5812 bytes - a difference of 92 bytes. How much of that is due to generated code by the exception handling and how much is due to the inclusion of std::exception and creation of the OverflowException class is unknown. (However, if I remove all STL exception stuff and have it simply throw an int, the resulting binary is 5800 bytes, which tells me that the exception class only contributed 12 bytes. Since storing the string "Overflow" requires 12 bytes, clearly there's somewhat more interdependent behavior than that going on.)

Verdict: too close to call.

Stack usage

Verdict: too close to call.

Run time

~$ time ./fib-1 38
Starting stack: 0xbff68b2c
Ending stack: 0xbff68440 (delta=-443)
f(38) = 63245986

real	0m2.091s
user	0m2.088s
sys	0m0.000s
~$ time ./fib-2 38
Starting stack: 0xbf9a3568
f(38) = 63245986
Ending stack: 0xbf9a2e60 (delta=-450)

real	0m1.866s
user	0m1.856s
sys	0m0.004s

Verdict: exceptions.

Conclusion

For execution time, in the (hopefully common) case that errors don't occur, exceptions are faster. This makes sense; checked error returns require checking every result, whether it's good or bad, while exceptions only have to do anything special when an error occurs. Now, given a sufficiently-complicated example (with lots of different exception types with a complex inheritance tree, for example), the error condition could very well take a lot of time to handle compared to simply checking an error return. In an environment where you'd expect there to be a lot of error conditions to handle (transitory failures, network hiccups, etc.) then error returns could very well turn out to be faster. But it seems that it'd be better to just use error returns for the circumstances which call for it, and to use exceptions everywhere else.

There is, of course, one major missing component to the memory use issue: the static data structures which have to be set up to begin with when the first try block starts. I don't know of a quick, platform-independent way to measure that. I also don't know what the impact is on a per-exception-type basis. However, those are essentially one-time costs, shared across every use of the exception type.

So, basically, my conclusion is that the only way you can be sure of which one works better for a given application is to write the application both ways, and see which one works better. However, my suspicion is that the small amount of memory overhead for exceptions is far outweighed by the time savings, reduced code complexity, and guarantee that errors are not simply ignored (unless they are explicitly ignored, and even ignoring exceptions means code was written to do so — and just putting a try{}catch(...){} at the top level will still do a lot more to "handle" an error than letting a return code drop on the floor).

Also, a larger, more meaningful comparison would do a better job of determining whether the generated code size (which is an issue for embedded systems! executables load entirely into memory on MMU-less systems) grows larger with exceptions or with error returns. I suspect that error returns will grow faster — there's more code that has to go into more places, unless you absolutely need fine-grained error checking. If you're wrapping a single line of code in a try/catch block, that would certainly be a good situation to use error returns in. But if you're dealing with larger functional units where one of several things could go wrong and abort an entire process, exceptions are probably the way to go.

Anyway, the most important thing is to not simply assume things based on "common knowledge," but to actually test them. People who have been working in a field for a long time tend to accumulate Ways of Doing Things and collections of assumptions based on how things were when they started. I used to assume exceptions were bad because that's what older, more experienced programmers than myself told me. But change can be good, and just because someone isn't as experienced in a given field doesn't mean they don't understand the issues. A fresh pair of eyes is always a good thing.