boost/more
1
0
Fork 0
mirror of https://github.com/boostorg/more.git synced 2024-12-27 23:40:13 +08:00
Code Issues Packages Projects Releases Wiki Activity

More catch(...) caveats

Browse Source 
[SVN r18083]
This commit is contained in:
Dave Abrahams 2003-03-25 17:42:24 +00:00
parent 54df10774c
commit b53c0ec6be
1 changed files with 13 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
error_handling.html
View File

@ -185,12 +185,22 @@ extern "C" void (*old_translator)(unsigned, EXCEPTION_POINTERS*)
system notification at a point where recovery is impossible look just
like a C++ exception thrown from a reasonable place, invalidating the
usual safe assumptions that destructors and catch blocks have taken valid
steps to ensure program invariants during unwinding. I reluctantly
concede this point to Hillel Y. Sims, who beat it into me (<wink>):
until all OSes are "fixed", if every exception were derived from
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
<code>catch(std::exception&amp;)</code> for <code>catch(...)</code>, the
world would be a better place.
<p>Sometimes, <code>catch(...)</code>, is still the most
appropriate pattern, in spite of bad interactions with OS/platform
design choices. If you have no idea what kind of exception might
be thrown and you really <i>must</i> stop unwinding it's probably
still your best bet. One obvious place where this occurs is at
language boundaries.
<hr>
<p>&copy; Copyright David Abrahams 2001-2003. Permission to copy,