mirror of
https://github.com/boostorg/more.git
synced 2025-02-27 09:40:06 +08:00
further updated guidelines
[SVN r18049]
This commit is contained in:
parent
70fc63b56b
commit
ca2a036c01
@ -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
|
||||
|
Loading…
Reference in New Issue
Block a user