diff options
author | Dave Abrahams <dave@boostpro.com> | 2003-03-22 15:01:27 +0000 |
---|---|---|
committer | Dave Abrahams <dave@boostpro.com> | 2003-03-22 15:01:27 +0000 |
commit | 56f1ed86ecb4dacdd452fac8aa8e8de4f1905d22 (patch) | |
tree | 04645d5cdeb7550935eb54ceb048a2914434cac3 | |
parent | 52f3862c6c9730c6ba969ea98fc2f43ccb623929 (diff) | |
download | boost-56f1ed86ecb4dacdd452fac8aa8e8de4f1905d22.tar.gz |
further updated guidelines
[SVN r18049]
-rw-r--r-- | more/error_handling.html | 35 |
1 files changed, 25 insertions, 10 deletions
diff --git a/more/error_handling.html b/more/error_handling.html index d804ecbba4..14035f4b0e 100644 --- a/more/error_handling.html +++ b/more/error_handling.html @@ -94,16 +94,31 @@ throw some_exception(); that you have a fallback in case the formatting code throws</li> <li><b>Don't worry <i>too</i> much about the <code>what()</code> - message</b>. It's nice to have a message that a programmer stands a - chance of figuring out, but you're very unlikely to be able to compose - a relevant and <i>user</i>-comprehensible error message at the point an - exception is thrown. Certainly, internationalization is beyond the - scope of the exception class author. <a href= - "../people/peter_dimov.htm">Peter Dimov</a> makes an excellent argument - that the proper use of a <code>what()</code> string is to serve as a - key into a table of error messages. Now if only we could get - standardized <code>what()</code> strings for exceptions thrown by the - standard library...</li> + message</b>. It's nice to have a message that a programmer + stands a chance of figuring out, but you're very unlikely to be + able to compose a relevant and <i>user</i>-comprehensible error + message at the point an exception is thrown. Certainly, + internationalization is beyond the scope of the exception class + author. <a href= + "../people/peter_dimov.htm">Peter Dimov</a> makes an excellent + argument that the proper use of a <code>what()</code> string is + to serve as a key into a table of error message formatters. Now + if only we could get standardized <code>what()</code> strings + for exceptions thrown by the standard library...</li> + + <li><b>Expose relevant information about the cause of the + error</b> in your exception class' public interface. A fixation + on the <code>what()</code> message is likely to mean that you + neglect to expose information someone might need in order to + make a coherent message for users. For example, if your + exception reports a numeric range error, it's important to have + the actual numbers involved available <i>as numbers</i> in the + exception class' public interface where error reporting code can + do something intelligent with them. If you only expose a + textual representation of those numbers in + the <code>what()</code> string, you will make life very + difficult for programmers who need to do something more + (e.g. subtraction) with them than dumb output. <li><b>Make your exception class immune to double-destruction</b> if possible. Unfortunately, several popular compilers occasionally cause |