Question

I don’t want a discussion about when to and not to throw exceptions. I wish to resolve a simple issue. 99% of the time the argument for not throwing exceptions revolves around them being slow while the other side claims (with benchmark test) that the speed is not the issue. I’ve read numerous blogs, articles, and posts pertaining one side or the other. So which is it?

Some links from the answers: Skeet, Mariani, Brumme.

Answer 1

I’m on the "not slow" side – or more precisely "not slow enough to make it worth avoiding them in normal use". I’ve written two short articles about this. There are criticisms of the benchmark aspect, which are mostly down to "in real life there’d be more stack to go through, so you’d blow the cache etc" – but using error codes to work your way up the stack would also blow the cache, so I don’t see that as a particularly good argument.

Just to make it clear – I don’t support using exceptions where they’re not logical. For instance, int.TryParse is entirely appropriate for converting data from a user. It’s inappropriate when reading a machine-generated file, where failure means "The file isn’t in the format it’s meant to be, I really don’t want to try to handle this as I don’t know what else might be wrong."

When using exceptions in "only reasonable circumstances" I’ve never seen an application whose performance was significantly impaired by exceptions. Basically, exceptions shouldn’t happen often unless you’ve got significant correctness issues, and if you’ve got significant correctness issues then performance isn’t the biggest problem you face.