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.5] Okay, so you're saying exception handling is easy and simple, right?

Wrong:

  • Exception handling is not a free lunch. It requires discipline and rigor. To understand those disciplines, you really should read the rest of the FAQ and/or one of the excellent books on the subject.
  • Exception handling is not a panacea. If you work with a team that is sloppy and undisciplined, your team will likely have problems no matter whether they use exceptions or return codes. Incompetent carpenters do bad work even if they use a good hammer.
  • Exception handling is not one-size-fits-all. Even when you have decided to use exceptions rather than return codes, that doesn't mean you use them for everything. This is part of the discipline: you need to know when a condition should be reported via return-code and when it should be reported via an exception.
  • Exception handling is a convenient whipping boy. If you work with people who blame their tools, beware of suggesting exceptions (or anything else that is new, for that matter). People whose ego is so fragile that they need to blame someone or something else for their screw-ups will invariably blame whatever "new" technology was used. Of course, ideally you will work with people who are emotionally capable of learning and growing: with them, you can make all sorts of suggestions, because those sorts of people will find a way to make it work, and you'll have fun in the process.

Fortunately there is plenty of wisdom and insight on the proper use of exceptions. Exception handling is not new. The industry as a whole has seen many millions of lines of code and many person-centuries of effort using exceptions. The jury has returned its verdict: exceptions can be used properly, and when they are used properly, they improve code.

Learn how.