boost/more
1
0
Fork 0
mirror of https://github.com/boostorg/more.git synced 2025-01-15 02:30:08 +08:00
Code Issues Packages Projects Releases Wiki Activity

Updates for Overload publication

Browse Source 
[SVN r19475]
This commit is contained in:
Dave Abrahams 2003-08-06 14:28:10 +00:00
parent 626f22ca32
commit 9d42891f3d
1 changed files with 19 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
error_handling.html
View File

@ -41,16 +41,19 @@
guideline. After all, if you check for an error condition, then in some
sense you expect it to happen, or the check is wasted code.</p>
<p>A more appropriate question to ask is: ``do we want stack unwinding
here?'' Because actually handling an exception is likely to be
significantly slower than executing mainline code, you should also ask:
``Can I afford stack unwinding here?'' For example, a desktop application
performing a long computation might periodically check to see whether the
user had pressed a cancel button. Throwing an exception could allow the
operation to be cancelled gracefully. On the other hand, it would
probably be inappropriate to throw and <i>handle</i> exceptions in the
inner loop of this computation because that could have a significant
performance impact.</p>
<p>A more appropriate question to ask is: ``do we want stack
unwinding here?'' Because actually handling an exception is likely
to be significantly slower than executing mainline code, you
should also ask: ``Can I afford stack unwinding here?'' For
example, a desktop application performing a long computation might
periodically check to see whether the user had pressed a cancel
button. Throwing an exception could allow the operation to be
cancelled gracefully. On the other hand, it would probably be
inappropriate to throw and <i>handle</i> exceptions in the inner
loop of this computation because that could have a significant
performance impact. The guideline mentioned above has a grain of
truth in it: in time critical code, throwing an exception
should <em>be</em> the exception, not the rule.</p>
<h3>How should I design my exception classes?</h3>
@ -184,9 +187,10 @@ extern "C" void (*old_translator)(unsigned, EXCEPTION_POINTERS*)
usual safe assumptions that destructors and catch blocks have taken valid
steps to ensure program invariants during unwinding.
<p>I reluctantly concede this point to Hillel Y. Sims, who beat it into
me (&lt;wink&gt;): until all OSes are "fixed", if every exception were
derived from <code>std::exception</code> and everyone substituted
<p>I reluctantly concede this point to Hillel Y. Sims, after many
long debates in the newsgroups: until all OSes are "fixed", if
every exception were derived from <code>std::exception</code> and
everyone substituted
<code>catch(std::exception&amp;)</code> for <code>catch(...)</code>, the
world would be a better place.</p>
@ -197,15 +201,11 @@ extern "C" void (*old_translator)(unsigned, EXCEPTION_POINTERS*)
place where this occurs is at language boundaries.</p>
<hr>
<p>&copy; Copyright David Abrahams 2001-2003. Permission to copy, use,
modify, sell and distribute this document is granted provided this
copyright notice appears in all copies. This document is provided "as is"
without express or implied warranty, and with no claim as to its
suitability for any purpose.</p>
<p>&copy; Copyright David Abrahams 2001-2003. All rights reserved.</p>
<p>Revised
<!--webbot bot="Timestamp" s-type="EDITED" s-format="%d %B, %Y" startspan -->
25 March, 2003<!--webbot bot="Timestamp" endspan i-checksum="34359" -->
6 August, 2003<!--webbot bot="Timestamp" endspan i-checksum="34359" -->
</p>
</body>
</html>