C++ FAQ Celebrating Twenty-One Years of the C++ FAQ!!!
(Click here for a personal note from Marshall Cline.)
Section 17:
17.1 What are some ways try / catch / throw can improve software quality?
17.2 Do the benefits of exceptions show up with tiny programs?
17.3 How do exceptions simplify my function return type and parameter types?
17.4 Do exceptions separate the "happy path" from the "bad path"?
17.5 Okay, so you're saying exception handling is easy and simple, right?
17.6 Mindset and discipline for exception handling?
17.7 I have too many try blocks; what can I do about it?
17.8 How can I handle a constructor that fails?
17.9 How can I handle a destructor that fails?
17.10 How should I handle resources if my constructors may throw exceptions?
17.11 How to prevent memory leaks when exceptions are thrown?
17.12 What should I throw?
17.13 What should I catch?
17.14 But MFC seems to encourage the use of catch-by-pointer; should I do the same?
17.15 Meaning and use of throw; (without an object)?
17.16 How do I throw polymorphically?
17.17 When I throw this object, how many times will it be copied?
[17.1] What are some ways try / catch / throw can improve software quality?

By eliminating one of the reasons for if statements.

The commonly used alternative to try / catch / throw is to return a return code (sometimes called an error code) that the caller explicitly tests via some conditional statement such as if. For example, printf(), scanf() and malloc() work this way: the caller is supposed to test the return value to see if the function succeeded.

Although the return code technique is sometimes the most appropriate error handling technique, there are some nasty side effects to adding unnecessary if statements:

  • Degrade quality: It is well known that conditional statements are approximately ten times more likely to contain errors than any other kind of statement. So all other things being equal, if you can eliminate conditionals / conditional statements from your code, you will likely have more robust code.
  • Slow down time-to-market: Since conditional statements are branch points which are related to the number of test cases that are needed for white-box testing, unnecessary conditional statements increase the amount of time that needs to be devoted to testing. Basically if you don't exercise every branch point, there will be instructions in your code that will never have been executed under test conditions until they are seen by your users/customers. That's bad.
  • Increase development cost: Bug finding, bug fixing, and testing are all increased by unnecessary control flow complexity.

So compared to error reporting via return-codes and if, using try / catch / throw is likely to result in code that has fewer bugs, is less expensive to develop, and has faster time-to-market. Of course if your organization doesn't have any experiential knowledge of try / catch / throw, you might want to use it on a toy project first just to make sure you know what you're doing — you should always get used to a weapon on the firing range before you bring it to the front lines of a shooting war.