How to work with unchecked exceptions?

Question

Java has compiler checked exceptions. When I made transition to C++, I learned it doesn't feature checked exceptions. At first, I kept using exception handling, because it's a great feature. However, after a while I abandoned it, because I got into a situation every function might throw an exception. As only a small percentage of the functions I write can throw exceptions (say some 25% at the most), I found the overhead of doing exception handling for functions that cannot throw anything unacceptable.

Because of this, I am really surprised that there are a lot of developers who prefer unchecked exceptions. Therefore, I am curious to know how they handle this problem. How do you avoid the overhead of doing unnecessary exception handling in case the language doesn't support checked exceptions?

Remark: My question equally applies to C++ and C#, and probably to all other languages that don't feature compiler checked exception handling.

Answer 1

Simple. You don't do exception handling in "every function that might throw" - in C++, just about every function might do so. Instead, you do it at certain key points in your application, where you can produce a sensible, application-specific diagnostic and take sensible, application-specific corrective action, although use of the RAII idiom means (as avakar points out in his answer) that there is often little corrective action to be taken.

Answer 2

When I first started using C# I was scared by this too. Then I found that actually, it doesn't matter very often. I very rarely find that I can catch an exception and so something useful with it anyway... almost all my exceptions bubble up to somewhere near the top of the stack anyway, where they're handled by aborting the request or whatever.

Now when I'm writing Java, I find checked exceptions intensely frustrating a lot of the time. I think there's value in there somewhere, but it introduces as many problems as it solves.

Basically, I think we haven't really got the whole error handling side of things "right" yet, but on balance I prefer the C# approach to the Java approach.

Answer 3

In addition to what Neil said, you should note that there is no need for try/finally (or in context of C++ try/catch/throw), because object destructors are called even if an exception is thrown.

It is easily possible to have exception-safe code with very few try statements.

Answer 4

For C++ specifically, the overhead pretty much goes away if you design your classes well and use RAII.

Martin York has written a wonderful example of that in this answer.

The function can stll throw an exception, yes, but if it does, it won't need to do anything special to clean up. So you only need to actually catch the exception in one place -- the function that is able to handle it and recover from the error.