Exceptions

Exceptions
Prev	Chapter 3. Using	Next

+The C++ language provides language support for stack unwinding +with try and catch blocks and +the throw keyword. +

+These are very powerful constructs, and require some thought when +applied to the standard library in order to yield components that work +efficiently while cleaning up resources when unexpectedly killed via +exceptional circumstances. +

+Two general topics of discussion follow: +exception neutrality and exception safety. +

Before detailing the library support + for -fno-exceptions, first a passing note on + the things lost when this flag is used: it will break exceptions + trying to pass through code compiled + with -fno-exceptions whether or not that code + has any try or catch + constructs. If you might have some code that throws, you shouldn't + use -fno-exceptions. If you have some code that + uses try or catch, you + shouldn't use -fno-exceptions. +

+ And what it to be gained, tinkering in the back alleys with a + language like this? Exception handling overhead can be measured + in the size of the executable binary, and varies with the + capabilities of the underlying operating system and specific + configuration of the C++ compiler. On recent hardware with GNU + system software of the same age, the combined code and data size + overhead for enabling exception handling is around 7%. Of course, + if code size is of singular concern than using the appropriate + optimizer setting with exception handling enabled + (ie, -Os -fexceptions) may save up to twice + that, and preserve error checking. +

+ So. Hell bent, we race down the slippery track, knowing the brakes + are a little soft and that the right front wheel has a tendency to + wobble at speed. Go on: detail the standard library support + for -fno-exceptions. +

+ In sum, valid C++ code with exception handling is transformed into + a dialect without exception handling. In detailed steps: all use + of the C++ + keywords try, catch, + and throw in the standard library have been + permanently replaced with the pre-processor controlled equivalents + spelled __try, __catch, + and __throw_exception_again. They are defined + as follows. +

+#ifdef __EXCEPTIONS
+# define __try      try
+# define __catch(X) catch(X)
+# define __throw_exception_again throw
+#else
+# define __try      if (true)
+# define __catch(X) if (false)
+# define __throw_exception_again
+#endif
+

+ In addition, for every object derived from + class exception, there exists a corresponding + function with C language linkage. An example: +

+#ifdef __EXCEPTIONS
+  void __throw_bad_exception(void)
+  { throw bad_exception(); }
+#else
+  void __throw_bad_exception(void)
+  { abort(); }
+#endif
+

+ The last language feature needing to be transformed + by -fno-exceptions is treatment of exception + specifications on member functions. Fortunately, the compiler deals + with this by ignoring exception specifications and so no alternate + source markup is needed. +

+ By using this combination of language re-specification by the + compiler, and the pre-processor tricks and the functional + indirection layer for thrown exception objects by the library, + libstdc++ files can be compiled + with -fno-exceptions. +

+ User code that uses C++ keywords + like throw, try, + and catch will produce errors even if the user + code has included libstdc++ headers and is using constructs + like basic_iostream. Even though the standard + library has been transformed, user code may need modification. User + code that attempts or expects to do error checking on standard + library components compiled with exception handling disabled should + be evaluated and potentially made conditional. +

+ Some issues remain with this approach (see bugzilla entry + 25191). Code paths are not equivalent, in + particular catch blocks are not evaluated. Also + problematic are throw expressions expecting a + user-defined throw handler. Known problem areas in the standard + library include using an instance + of basic_istream + with exceptions set to specific + ios_base::iostate conditions, or + cascading catch blocks that dispatch error + handling or recovery efforts based on the type of exception object + thrown. +

+ Oh, and by the way: none of this hackery is at all + special. (Although perhaps well-deserving of a raised eyebrow.) + Support continues to evolve and may change in the future. Similar + and even additional techniques are used in other C++ libraries and + compilers. +

+ C++ hackers with a bent for language and control-flow purity have + been successfully consoled by grizzled C veterans lamenting the + substitution of the C language keyword + const with the uglified + doppelganger __const. +

Compatibility

With `C`

+ C language code that is expecting to interoperate with C++ should be + compiled with -fexceptions. This will make + debugging a C language function called as part of C++-induced stack + unwinding possible. +

+ In particular, unwinding into a frame with no exception handling +data will cause a runtime abort. If the unwinder runs out of unwind +info before it finds a handler, std::terminate() +is called. +

+ Please note that most development environments should take care of + getting these details right. For GNU systems, all appropriate parts + of the GNU C library are already compiled + with -fexceptions. +

With `POSIX` thread cancellation

+ GNU systems re-use some of the exception handling mechanisms to + track control flow for POSIX thread cancellation. +

+ Cancellation points are functions defined by POSIX as worthy of + special treatment. The standard library may use some of these + functions to implement parts of the ISO C++ standard or depend on + them for extensions. +

+ Of note: +

+ nanosleep, + read, write, open, close, + and wait. +

+ The parts of libstdc++ that use C library functions marked as + cancellation points should take pains to be exception neutral. + Failing this, catch blocks have been augmented to + show that the POSIX cancellation object is in flight. +

+ This augmentation adds a catch block + for __cxxabiv1::__forced_unwind, which is the + object representing the POSIX cancellation object. Like so: +

+  catch(const __cxxabiv1::__forced_unwind&)
+  {
+    this->_M_setstate(ios_base::badbit);
+    throw;
+  }
+  catch(...)
+  { this->_M_setstate(ios_base::badbit); }
+

Bibliography

+ . + System Interface Definitions, Issue 7 (IEEE Std. 1003.1-2008) + . + 2.9.5 Thread Cancellation + . Copyright © 2008 + The Open Group/The Institute of Electrical and Electronics + Engineers, Inc. + .

+ . + Error and Exception Handling + . David Abrahams . + Boost + .

+ . + Exception-Safety in Generic Components + . David Abrahams. + Boost + .

+ . + Standard Library Exception Policy + . Matt Austern. + WG21 N1077 + .

+ . + ia64 c++ abi exception handling + . Richard Henderson. + GNU + .

+ . + Appendix E: Standard-Library Exception Safety + . Bjarne Stroustrup.

+ Exceptional C++ + . + Exception-Safety Issues and Techniques + . Herb Sutter.

+ . + GCC Bug 25191: exception_defines.h #defines try/catch + .

Prev	Up	Next
Concurrency	Home	Debugging Support