What do You Use C++ Exceptions For?

Question

Probably exceptions is the most controversial C++ feature. Many teams including google do not use them. Of course the decision to use them or not depends on the context -- for example, in some games it might be ok to crash on out-of-memory, but not in a medical equipment control software. Apart from out-of-memory, some teams may use exceptions for network disruption, file-not-found etc. but others may say this is too common to be called an exception (others may say, but if it is common, so what?)

Often the decision not to use exceptions is based on the potentially misguided argument that it is difficult to write exception-safe code. Some people say the argument is misguided because using the alternative of using error codes will lead to at least as much difficult code. David Abrahams clarifies this point.

In this question, I am curious to know:

• For what cases do you use exceptions?
• What is the context of your application? Why can't you live without exceptions?
• How do you manage to write exception-safe code? What is the level of investment you have to make?
• Is/Was it worth it?

Answer 1

I use exceptions for exceptional behaviour, and not too frequently. When debugging crashes, I frequently use break-on-exception, so if your code is using exceptions to handle things that normally occur, I shall be quietly fuming at you. Use them when things have gone wrong in an unexpected way.

Acceptable example: server your code relies on is unavailable, so your service cannot do anything meaningful.

Example that means I'm annoyed at your code: user entered a number greater than 100, as input to your function which expects a number <=100.

In fact, if you're working on a user-facing application, the user probably shouldn't be able to do anything that generates an exception.

This is a very grey area though, so feel free to upvote/downvote me if you agree/disagree. If you disagree please post a comment saying why - I'm curious to hear other guidelines/rules/metrics.

Answer 2

In my experience if I use exceptions to "smartly" recover the exception handling tends to over time become more and more complex when it finally adds way too much overhead compared to value. Instead I have adopted the approach of using exceptions purely for detection, having an exception thrown in a function and logging it at that point allows me to faster find ev. problems. Using hierarchies where you rethrow the exception to capture it in a higher level well I tried that but find it makes the code unnecessarily difficult to follow without a major benefit.

Answer 3

Although a lot of people treat exceptions in C++ really as 'something exceptional happened', I find them incredibly handy to do basic error-checking / validation as well, mostly at application-level (as in not in the core of the library)

Example, I'd rather write

try
{
  MethodA();
  MethodB();
  //.. a whole lot of other methods crucial to succeed for app initialization
}
catch( const SomeException& e )
{
  //show user the critical error contained in e
  return 1;
}

then writing

if( !MethodA() )
{
  //retrieve and show error
  return 1;
}
if( !MethodB() || !MethodC() )
{
  //retrieve and show error
  return 1;
}
//etc

This tends to lead to less code, also within the methods themselves.

Answer 4

I'm generally pro-exception for truly exceptional situations, but I probably have a higher bar than most in deciding what's "exceptional".

What makes this hard is that the low-level code must decide what's exceptional, but only the high-level code knows whether a given error is exceptional. For example, consider a function that loads an icon. What should it do when it fails? Only the calling code knows whether the failure is critical (the program NEEDS that icon to proceed) or not (the icon is just decorative).

Practical issues tend to trump elegance. Constructors that fail have to throw exceptions in order for RAII to work. On the other hand, destructors shouldn't throw exceptions. Then there are all the barriers across which you cannot let an exception fly. For example, in Windows, it's not safe to let an exception propagate out of an OS callback (like a window procedure). If you're multi-threaded, an unhandled exception in one of your worker threads will bring down the process, without unwinding and calling the d'tors on your other threads. Device drivers and kernel code generally cannot use C++-style exceptions because of paging constraints. COM doesn't play nice with exceptions.

Answer 5

Last time I used them:

throw "Constant (appropriate) error message"

when encountering a serious condition.

A couple of times I stuck extra data in global variables, but that was before I wrote multi-threaded code. I'd have to rethink that one (obviously).

Not that I'd recommend this technique anymore.

Answer 6

Almost everybody writes code can throw exceptions. They're all over the standard libraries. Given that, I don't think a "no exception" policy is a good one.

I don't write my own exception-throwing code much, because I don't directly deal with that many things that are likely to go wrong such that throwing would be useful. If something goes seriously wrong where there's no obvious way to fix it, throwing is a good idea.

I do try to make sure that what I write will work sanely in case of exceptions being thrown.