[Exceptional C++ Style] Item 12: Exception Safety: Is it Worth it?

Falcon, Pablo (IT) Pablo.Falcon at morganstanley.com
Thu Dec 2 05:33:28 EST 2004


Hello all,
 
  This is my summary for item 12. Not a very complex item to summarize
but I guess one that could generate some controversy.
 
Regards,
 
Pablo
 
------------------------------------------------------------------------
------------------------------------------------------------------------
---
Summary for ITEM 12: Exception Safety: Is it Worth it?
 
The author answers the question on whether it is worth writing
exception-safe code or not. 

It starts with a summary of the Abrahams Guarantees:
 
  * Basic Guarantee: failed operations may alter program state in a
non-predictable way, but program has to remain in a consistent and
usable state.
 
  * Strong Guarantee: failed operations do not alter program state.
Transactional commit/rollback semantics.
 
  * Nofail Guarantee (formerly Nothrow guarantee): operations will not
throw an exception.
 
The discussion then addresses why it is good to write code that
satisfies at least one of these guarantees and which of them should be
targeted depending on the situation.
 
On the first issue, why it is generally good to write exception-safe
code, the author highlights the following points:
 
  1.- Code has to be prepared to deal with exceptions, as it is a
language feature that is used by many, including the standard library
and the language itself.
 
  2.- Writing exception-safe code is good in general, because it
enforces good coding practices like:
          
      - Resource Acquisition is Initialization (RAII).
      - Transactional Programming ("do all the work on one side then
swap"). This approach is safer and cleaner whatever the error reporting
methodology used, as it ensures things are not left half-baked in case
of failure.
      - One class(method), one responsibility: Functions with multiple
effects should be discoraged in general.
 
On the second issue of when should we apply which guarantee, the author
gives a good summary himself: A function should always support the
strictest guarantee that it can support without penalizing callers who
don't need it. 
 
As an example of a case where users would be penalized we have
vector::insert(), making this method comply with the strong guarantee
would seriously affect its performance, and this cannot be accepted by
many users of this method. The callers can also wrap this method and
implement the strong guarantee themselves, if they need to.

------------------------------------------------------------------------
------------------------------------------------------------------------
---
Pablo Falcon 
Morgan Stanley | Technology
25 Cabot Square | Canary Wharf | Floor 03
London, E14 4QA
Phone: +44 20 7425-9714
Mobile: +44 79497-43014
Fax: +44 20 7677-2703
Pablo.Falcon at morganstanley.com 
--------------------------------------------------------
 
NOTICE: If received in error, please destroy and notify sender.  Sender does not waive confidentiality or privilege, and use is prohibited. 
 


--- StripMime Report -- processed MIME parts ---
multipart/alternative
  text/plain (text body -- kept)
  text/html
---



More information about the Effective-cpp mailing list