Dr. Dobb's Journal - December 2007 - (Page 46)

d12gran_p5ma 10/12/07 10:23 AM Page 46 Core Technology by Calum Grant Transactional Programming Database techniques applied to C++ development When programs encounter exceptions, they must not leave data in an inconsistent state. It Calum, who holds a Ph.D. in Computer Science from the University of Cambridge, is a senior software engineer at Sophos Plc. He can be contacted at calum.grant@sophos.com. would be no good for a function to half-complete because that could leave the data in an unexpected state and lead to bugs later in the program. But this is exactly what can happen when exceptions are thrown halfway through a function. For example, the problem with this function: std::vector list1, list2; void f(const std::string &s) { list1.push_back(s); list2.push_back(s); } is that the second push_back() might fail and throw std::bad_alloc. This would leave the program in an inconsistent state because list1 and list2 are different. While desktop computers rarely deny a memory request, std::bad_alloc should be anticipated on portable devices or servers. In an ideal world, functions should either completely succeed or fail without side effects. This all-ornothing behavior is referred to as “atomic” because it will never leave the program in a halfway state. A way of describing the effects of exceptions on functions is with Abrahams guarantees [1]: • Basic Guarantee. If an exception is thrown, no resources are leaked and objects remain in a destructible and usable—but not necessarily predictable—state. • Strong Guarantee. If an exception is thrown, the program state remains unchanged. • Nothrow Guarantee. The function will not emit an exception under any circumstances. Although the nothrow guarantee sounds ideal, it is often impossible to arrange for a function to never throw an exception, especially when memory alloca46 Dr. Dobb’s Journal l www.ddj.com l December 2007 tion takes place, which could throw std::bad_alloc at an inopportune moment. Many standard library containers rely on memory allocation and could, therefore, throw. The basic guarantee is often not good enough, since leaving a program in a safe but indeterminate state is not terribly useful. It is much better to live with exceptions, and let them propagate out to the caller in a safe and predictable way. But error recovery is not straightforward in C++. When an exception is thrown, all of the side effects prior to the exception must be undone. In real code this is not often done, or it is added as an afterthought. Even when exceptions are considered up front, analyzing them and recovering from them is difficult and error prone. Exceptional paths are generally the least tested part of software—it is impractical to unit-test every exceptional path caused by std::bad_alloc. While the best solution is to try to redesign the data structures, this isn’t always possible. Consequently, you might try to catch the second exception and undo the push_back() on list1: void f(const std::string &s) { list1.push_back(s); try { list2.push_back(s); } catch( ) { list1.pop_back(); throw; } } http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - December 2007

Dr. Dobb's Journal - December 2007 Contents Hmmmm Alia Vox Developer Diaries Developer’s Notebook Computer Books: Reading Between the Lines Conversations Query Anything with SQLite XQuery Web Maps with the Google Map API OpenALM and Its Manifesto Transactional Programming Effective Concurrency The Agile Edge Swaine’s Flames

Dr. Dobb's Journal - December 2007

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.