Question

It’s often said that you shouldn’t use exceptions for regular error handling because of bad performance. My guess is that that bad performance is caused by having to instantiate a new exception object, generate a stack trace, etc. So why not have lightweight exceptions? Code like this is logically sound:

string ageDescription = "Five years old";
try {
    int age = int.Parse(ageDescription);
}
catch (Exception) {
    // Couldn't parse age; handle parse failure
}

And yet we’re recommended to use TryParse instead to avoid the overhead of the exception. But if the exception were just a static object that got initialized when the thread started, all the code throwing the exception would need to do is set an error code number and maybe an error string. No stack trace, no new object instantiation. It would be a “lightweight exception”, and so the overhead for using exceptions would be greatly reduced. Why don’t we have such lightweight exceptions?

Answer 1

The performance hit isn’t just because you’re creating a new Exception object. A lot of it has to do with the conditional unwinding of the stack that needs to be done when an exception occurs.

For example, think about the work that would have to be done when you have exception handlers that catch different kinds of exceptions. At each point in the stack, as it’s unwound from callee to caller, the language must do a type check to see not only if the exception can be handled, but what the most appropriate handler is. That’s a significant amount of overhead in its own right.

If you really want to be lightweight, you should return a result from your functions — that’s what Int32.TryParse() does. No stack unwinding, no type checking, just a simple condition which can easily be optimized for.

EDIT: One somewhat interesting thing to note is that C# was created after Java. Java has a couple of interesting constructs which cause exception handling to be more complicated than what we see in C#, namely checked exceptions and the throws keyword. Kind of interesting reads. I’m (personally) glad that C# didn’t include this “feature”. My guess is that they bifurcated their exception handlers to boost performance. In the real world, as I understand it, a LOT of developers just end up specifying throws exception in their function declarations.