| 1 | <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN"> |
|---|
| 2 | |
|---|
| 3 | <html> |
|---|
| 4 | <head> |
|---|
| 5 | <meta name="generator" content= |
|---|
| 6 | "HTML Tidy for Cygwin (vers 1st April 2002), see www.w3.org"> |
|---|
| 7 | <meta http-equiv="Content-Type" content= |
|---|
| 8 | "text/html; charset=windows-1252"> |
|---|
| 9 | |
|---|
| 10 | <title>Error and Exception Handling</title> |
|---|
| 11 | </head> |
|---|
| 12 | |
|---|
| 13 | <body> |
|---|
| 14 | <h1>Error and Exception Handling</h1> |
|---|
| 15 | |
|---|
| 16 | <h2>References</h2> |
|---|
| 17 | |
|---|
| 18 | <p>The following paper is a good introduction to some of the issues of |
|---|
| 19 | writing robust generic components:</p> |
|---|
| 20 | |
|---|
| 21 | <blockquote> |
|---|
| 22 | <a href="generic_exception_safety.html">D. Abrahams: ``Exception Safety |
|---|
| 23 | in Generic Components''</a>, originally published in <a href= |
|---|
| 24 | "http://www.springer.de/cgi-bin/search_book.pl?isbn=3-540-41090-2">M. |
|---|
| 25 | Jazayeri, R. Loos, D. Musser (eds.): Generic Programming, Proc. of a |
|---|
| 26 | Dagstuhl Seminar, Lecture Notes on Computer Science. Volume. 1766</a> |
|---|
| 27 | </blockquote> |
|---|
| 28 | |
|---|
| 29 | <h2>Guidelines</h2> |
|---|
| 30 | |
|---|
| 31 | <h3>When should I use exceptions?</h3> |
|---|
| 32 | |
|---|
| 33 | <p>The simple answer is: ``whenever the semantic and performance |
|---|
| 34 | characteristics of exceptions are appropriate.''</p> |
|---|
| 35 | |
|---|
| 36 | <p>An oft-cited guideline is to ask yourself the question ``is this an |
|---|
| 37 | exceptional (or unexpected) situation?'' This guideline has an attractive |
|---|
| 38 | ring to it, but is usually a mistake. The problem is that one person's |
|---|
| 39 | ``exceptional'' is another's ``expected'': when you really look at the |
|---|
| 40 | terms carefully, the distinction evaporates and you're left with no |
|---|
| 41 | guideline. After all, if you check for an error condition, then in some |
|---|
| 42 | sense you expect it to happen, or the check is wasted code.</p> |
|---|
| 43 | |
|---|
| 44 | <p>A more appropriate question to ask is: ``do we want stack |
|---|
| 45 | unwinding here?'' Because actually handling an exception is likely |
|---|
| 46 | to be significantly slower than executing mainline code, you |
|---|
| 47 | should also ask: ``Can I afford stack unwinding here?'' For |
|---|
| 48 | example, a desktop application performing a long computation might |
|---|
| 49 | periodically check to see whether the user had pressed a cancel |
|---|
| 50 | button. Throwing an exception could allow the operation to be |
|---|
| 51 | cancelled gracefully. On the other hand, it would probably be |
|---|
| 52 | inappropriate to throw and <i>handle</i> exceptions in the inner |
|---|
| 53 | loop of this computation because that could have a significant |
|---|
| 54 | performance impact. The guideline mentioned above has a grain of |
|---|
| 55 | truth in it: in time critical code, throwing an exception |
|---|
| 56 | should <em>be</em> the exception, not the rule.</p> |
|---|
| 57 | |
|---|
| 58 | <h3>How should I design my exception classes?</h3> |
|---|
| 59 | |
|---|
| 60 | <ol> |
|---|
| 61 | <li><b>Derive your exception class |
|---|
| 62 | from <code>std::exception</code></b>. Except in *very* rare |
|---|
| 63 | circumstances where you can't afford the cost of a virtual |
|---|
| 64 | table, |
|---|
| 65 | <code>std::exception</code> makes a reasonable exception base class, |
|---|
| 66 | and when used universally, allows programmers to catch "everything" |
|---|
| 67 | without resorting to <code>catch(...)</code>. For more about |
|---|
| 68 | <code>catch(...)</code>, see below. |
|---|
| 69 | |
|---|
| 70 | <li><b>Use <i>virtual</i> inheritance.</b> This insight is due |
|---|
| 71 | to Andrew Koenig. Using virtual inheritance from your |
|---|
| 72 | exception's base class(es) prevents ambiguity problems at the |
|---|
| 73 | catch-site in case someone throws an exception derived from |
|---|
| 74 | multiple bases which have a base class in common: |
|---|
| 75 | |
|---|
| 76 | <pre> |
|---|
| 77 | #include <iostream> |
|---|
| 78 | struct my_exc1 : std::exception { char const* what() const throw(); }; |
|---|
| 79 | struct my_exc2 : std::exception { char const* what() const throw(); }; |
|---|
| 80 | struct your_exc3 : my_exc1, my_exc2 {}; |
|---|
| 81 | |
|---|
| 82 | int main() |
|---|
| 83 | { |
|---|
| 84 | try { throw your_exc3(); } |
|---|
| 85 | catch(std::exception const& e) {} |
|---|
| 86 | catch(...) { std::cout << "whoops!" << std::endl; } |
|---|
| 87 | } |
|---|
| 88 | </pre> |
|---|
| 89 | |
|---|
| 90 | The program above prints <code>"whoops"</code> because the |
|---|
| 91 | C++ runtime can't resolve which <code>exception</code> instance to |
|---|
| 92 | match in the first catch clause. |
|---|
| 93 | |
|---|
| 94 | </li> |
|---|
| 95 | |
|---|
| 96 | <li> |
|---|
| 97 | <b><i>Don't</i> embed a std::string object</b> or any other data |
|---|
| 98 | member or base class whose copy constructor could throw an exception. |
|---|
| 99 | That could lead directly to std::terminate() at the throw point. |
|---|
| 100 | Similarly, it's a bad idea to use a base or member whose ordinary |
|---|
| 101 | constructor(s) might throw, because, though not necessarily fatal to |
|---|
| 102 | your program, you may report a different exception than intended from |
|---|
| 103 | a <i>throw-expression</i> that includes construction such as: |
|---|
| 104 | |
|---|
| 105 | <blockquote> |
|---|
| 106 | <pre> |
|---|
| 107 | throw some_exception(); |
|---|
| 108 | </pre> |
|---|
| 109 | </blockquote> |
|---|
| 110 | |
|---|
| 111 | <p>There are various ways to avoid copying string objects when |
|---|
| 112 | exceptions are copied, including embedding a fixed-length buffer in |
|---|
| 113 | the exception object, or managing strings via reference-counting. |
|---|
| 114 | However, consider the next point before pursuing either of these |
|---|
| 115 | approaches.</p> |
|---|
| 116 | </li> |
|---|
| 117 | |
|---|
| 118 | <li><b>Format the <code>what()</code> message on demand</b>, if you |
|---|
| 119 | feel you really must format the message. Formatting an exception error |
|---|
| 120 | message is typically a memory-intensive operation that could |
|---|
| 121 | potentially throw an exception. This is an operation best delayed until |
|---|
| 122 | after stack unwinding has occurred, and presumably, released some |
|---|
| 123 | resources. It's a good idea in this case to protect your |
|---|
| 124 | <code>what()</code> function with a <code>catch(...)</code> block so |
|---|
| 125 | that you have a fallback in case the formatting code throws</li> |
|---|
| 126 | |
|---|
| 127 | <li><b>Don't worry <i>too</i> much about the <code>what()</code> |
|---|
| 128 | message</b>. It's nice to have a message that a programmer stands a |
|---|
| 129 | chance of figuring out, but you're very unlikely to be able to compose |
|---|
| 130 | a relevant and <i>user</i>-comprehensible error message at the point an |
|---|
| 131 | exception is thrown. Certainly, internationalization is beyond the |
|---|
| 132 | scope of the exception class author. <a href= |
|---|
| 133 | "../people/peter_dimov.htm">Peter Dimov</a> makes an excellent argument |
|---|
| 134 | that the proper use of a <code>what()</code> string is to serve as a |
|---|
| 135 | key into a table of error message formatters. Now if only we could get |
|---|
| 136 | standardized <code>what()</code> strings for exceptions thrown by the |
|---|
| 137 | standard library...</li> |
|---|
| 138 | |
|---|
| 139 | <li><b>Expose relevant information about the cause of the error</b> in |
|---|
| 140 | your exception class' public interface. A fixation on the |
|---|
| 141 | <code>what()</code> message is likely to mean that you neglect to |
|---|
| 142 | expose information someone might need in order to make a coherent |
|---|
| 143 | message for users. For example, if your exception reports a numeric |
|---|
| 144 | range error, it's important to have the actual numbers involved |
|---|
| 145 | available <i>as numbers</i> in the exception class' public interface |
|---|
| 146 | where error reporting code can do something intelligent with them. If |
|---|
| 147 | you only expose a textual representation of those numbers in the |
|---|
| 148 | <code>what()</code> string, you will make life very difficult for |
|---|
| 149 | programmers who need to do something more (e.g. subtraction) with them |
|---|
| 150 | than dumb output.</li> |
|---|
| 151 | |
|---|
| 152 | <li><b>Make your exception class immune to double-destruction</b> if |
|---|
| 153 | possible. Unfortunately, several popular compilers occasionally cause |
|---|
| 154 | exception objects to be destroyed twice. If you can arrange for that to |
|---|
| 155 | be harmless (e.g. by zeroing deleted pointers) your code will be more |
|---|
| 156 | robust.</li> |
|---|
| 157 | </ol> |
|---|
| 158 | |
|---|
| 159 | <h3>What About Programmer Errors?</h3> |
|---|
| 160 | |
|---|
| 161 | <p>As a developer, if I have violated a precondition of a library I'm |
|---|
| 162 | using, I don't want stack unwinding. What I want is a core dump or the |
|---|
| 163 | equivalent - a way to inspect the state of the program at the exact point |
|---|
| 164 | where the problem was detected. That usually means <tt>assert()</tt> or |
|---|
| 165 | something like it.</p> |
|---|
| 166 | |
|---|
| 167 | <p>Sometimes it is necessary to have resilient APIs which can stand up to |
|---|
| 168 | nearly any kind of client abuse, but there is usually a significant cost |
|---|
| 169 | to this approach. For example, it usually requires that each object used |
|---|
| 170 | by a client be tracked so that it can be checked for validity. If you |
|---|
| 171 | need that sort of protection, it can usually be provided as a layer on |
|---|
| 172 | top of a simpler API. Beware half-measures, though. An API which promises |
|---|
| 173 | resilience against some, but not all abuse is an invitation to disaster. |
|---|
| 174 | Clients will begin to rely on the protection and their expectations will |
|---|
| 175 | grow to cover unprotected parts of the interface.</p> |
|---|
| 176 | |
|---|
| 177 | <p><b>Note for Windows developers</b>: unfortunately, the native |
|---|
| 178 | exception-handling used by most Windows compilers actually throws an |
|---|
| 179 | exception when you use <tt>assert()</tt>. Actually, this is true of other |
|---|
| 180 | programmer errors such as segmentation faults and divide-by-zero errors. |
|---|
| 181 | One problem with this is that if you use JIT (Just In Time) debugging, |
|---|
| 182 | there will be collateral exception-unwinding before the debugger comes up |
|---|
| 183 | because <code>catch(...)</code> will catch these not-really-C++ |
|---|
| 184 | exceptions. Fortunately, there is a simple but little-known workaround, |
|---|
| 185 | which is to use the following incantation:</p> |
|---|
| 186 | |
|---|
| 187 | <blockquote> |
|---|
| 188 | <pre> |
|---|
| 189 | extern "C" void straight_to_debugger(unsigned int, EXCEPTION_POINTERS*) |
|---|
| 190 | { |
|---|
| 191 | throw; |
|---|
| 192 | } |
|---|
| 193 | extern "C" void (*old_translator)(unsigned, EXCEPTION_POINTERS*) |
|---|
| 194 | = _set_se_translator(straight_to_debugger); |
|---|
| 195 | </pre> |
|---|
| 196 | </blockquote> |
|---|
| 197 | This technique doesn't work if the SEH is raised from within a catch |
|---|
| 198 | block (or a function called from within a catch block), but it still |
|---|
| 199 | eliminates the vast majority of JIT-masking problems. |
|---|
| 200 | |
|---|
| 201 | <h3>How should I handle exceptions?</h3> |
|---|
| 202 | |
|---|
| 203 | <p>Often the best way to deal with exceptions is to not handle them at |
|---|
| 204 | all. If you can let them pass through your code and allow destructors to |
|---|
| 205 | handle cleanup, your code will be cleaner.</p> |
|---|
| 206 | |
|---|
| 207 | <h4>Avoid <code>catch(...)</code> when possible</h4> |
|---|
| 208 | Unfortunately, operating systems other than Windows also wind non-C++ |
|---|
| 209 | "exceptions" (such as thread cancellation) into the C++ EH machinery, and |
|---|
| 210 | there is sometimes no workaround corresponding to the |
|---|
| 211 | <code>_set_se_translator</code> hack described above. The result is that |
|---|
| 212 | <code>catch(...)</code> can have the effect of making some unexpected |
|---|
| 213 | system notification at a point where recovery is impossible look just |
|---|
| 214 | like a C++ exception thrown from a reasonable place, invalidating the |
|---|
| 215 | usual safe assumptions that destructors and catch blocks have taken valid |
|---|
| 216 | steps to ensure program invariants during unwinding. |
|---|
| 217 | |
|---|
| 218 | <p>I reluctantly concede this point to Hillel Y. Sims, after many |
|---|
| 219 | long debates in the newsgroups: until all OSes are "fixed", if |
|---|
| 220 | every exception were derived from <code>std::exception</code> and |
|---|
| 221 | everyone substituted |
|---|
| 222 | <code>catch(std::exception&)</code> for <code>catch(...)</code>, the |
|---|
| 223 | world would be a better place.</p> |
|---|
| 224 | |
|---|
| 225 | <p>Sometimes, <code>catch(...)</code>, is still the most appropriate |
|---|
| 226 | pattern, in spite of bad interactions with OS/platform design choices. If |
|---|
| 227 | you have no idea what kind of exception might be thrown and you really |
|---|
| 228 | <i>must</i> stop unwinding it's probably still your best bet. One obvious |
|---|
| 229 | place where this occurs is at language boundaries.</p> |
|---|
| 230 | <hr> |
|---|
| 231 | |
|---|
| 232 | <p>© Copyright David Abrahams 2001-2003. All rights reserved.</p> |
|---|
| 233 | |
|---|
| 234 | <p>Revised |
|---|
| 235 | <!--webbot bot="Timestamp" s-type="EDITED" s-format="%d %B, %Y" startspan --> |
|---|
| 236 | 21 August, 2003<!--webbot bot="Timestamp" endspan i-checksum="34359" --> |
|---|
| 237 | </p> |
|---|
| 238 | </body> |
|---|
| 239 | </html> |
|---|
| 240 | |
|---|
