CSDN博客

img taodm

C与C++中的异常处理15

发表于2002/3/1 8:51:00  706人阅读

1.     模板安全(续)

    在异常安全的第二部分,我讲了在构造函数和析构函数中导致资源泄漏的问题。这次将探索另外两个问题。并且以推荐读物列表结束。

1.1     Problem #2get

    上次,我定义X::get()为:

T get()

   {

   return *value_;

   }

    这个定义有点小小的不足。既然get()不改变wrapper对象,我应该将它申明为const成员的:

T get() const

   {

   return *value_;

   }

    get()返回了一个T的临时对象。这个临时对象通过T的拷贝构造函数根据*value_隐式生成的,而这个构造函数可能抛异常。要避开这点,我们应该将get()修改为不返回任何东西:

void get(T &value) const throw()

   {

  value = *value_;

   }

    现在,get()接受一个事先构造好的T对象的引用,并通过引用“返回”结果。因为get()现在不调用T的构造函数了,它是异常安全的了。

    真的吗?

    很不幸,答案是“no”。我们只是将一个问题换成了另外一个问题而已,因为语句

value = *value_;

实际上是

value.operator=(*value_);

而它可能抛异常。更完备的解决方法是

void get(T &value) const throw()

   {

   try

      {

      value = *value_;

      }

   catch (...)

      {

      }

   }

    现在,get()不会将异常漏出去了。

    不过,工作还没完成。在operator=value赋值时抛异常的话,value将处于不确定状态。get()想要有最大程度的健壮接口的话,它必须两者有其一:

l         value根据*value_进行了完全设置,或

l         value没有被改变。

    这两条要将我们弄跳起来了:无论我们用什么方法来解决这个问题,我们都必须调用operator=来设置value,而如果operator=抛了异常,value将只被部分改变。

    我们的这个强壮接口看起来美却不实在。我们无法简单地实现它,只能提供一个弱些的承诺了:

l         value根据*value_进行了完全设置,或

l         value处于一个不确定的(错误)状态。

    但还有一个问题没解决:让调用者知道回传的value是否是“好的”。一个可能的解决方法(也很讽刺的)是抛出一个异常。另外一个可能方法,也是我在这儿采用的方法是返回一个错误码。

    修改后的get()是:

bool get(T &value) const throw()

   {

   bool error(false);

  try

     {

     value = *value_;

     }

  catch (...)

     {

      error = true;

     }

 

   return error;

   }

    提供了一个较弱的承诺的这个新接口是安全的。它行为安全吗?是的。wrapper所拥有的唯一资源是分配给*value_的内存,而它是受保护的,即使operator=抛了异常。

    符合最初的说明,get()有了一个健壮的异常安全承诺,即使T没有这个承诺。最终,我们过于加强了get()的承诺(这取决于value),而应该将它降低到T的承诺层次。我们用一个警告修正get()的承诺,基于我们不能控制或不能预知T的状态。In the end, we over-committed get's guarantee (the determinism of value), and had to bring it down to T's level. We amended get's contract with a caveat, based on conditions in T we couldn't control or predict.

    原则:程序的健壮性等于它最弱的承诺。尽可能提供最健壮的承诺,同时在行为和接口上。

    推论:如果你自己的接口的承诺比其他人的接口健壮,你通常必须将你的接口减弱到相匹配的程度。

 

1.2     Problem #3set

    我们现在的X::set()的实现是:

void set(T const &value)

   {

   *value_ = value;

   }

 

    (和get()不同,set()确实修改wrapper对象,所以不能申明为cosnt。)

    语句

*value_ = value;

应该看起来很熟悉:她只是前面Problem #2中提到的语句

value = *value_;

的反序。注意到这个变化,Problem #3的解决方案就和Problem #2的一样了:bool set(T const &value) throw()

   {

   bool error(false);

   try

      {

     *value = value_;

      }

   catch (...)

      {

      error = true;

      }

   return error;

   }

 

    和我们在get()中回传value遇到的问题一样:如果operator=抛了异常,我们无法知道*value_的状态。我们对get()的承诺的警告在这儿同样适用。

    get()set()现在有这同样的操作但不同的用途:get()将当前对象的值赋给另外一个对象,而set()将另外一个对象的值赋给当前对象。由于这种对称性,我们可以将共同的代码放入一个assign()函数:

static bool assign(T &to, T const &from) throw()

   {

   bool error(false);

   try

      {

      to = from;

      }

   catch (...)

      {

      error = true;

      }

   return error;

   }

 

    使用了这个辅助函数后,get()set()缩短为

bool get(T &value) const throw()

   {

   return assign(value, *value_);

   }

 

bool set(T const &value) throw()

   {

   return assign(*value_, value);

   }

 

1.3     最终版本

    wrapper的最终版本是

template <typename T>

class wrapper

   {

public:

   wrapper() throw()

         : value_(NULL)

      {

      try

         {

         value_ = new T;

         }

      catch (...)

         {

         }

      }

   ~wrapper() throw()

      {

      try

         {

         delete value_;

         }

      catch (...)

         {

         operator delete(value_);

         }

      }

   bool get(T &value) const throw()

      {

      return assign(value, *value_);

      }

   bool set(T const &value) throw()

      {

      return assign(*value_, value);

      }

private:

   bool assign(T &to, T const &from) throw()

      {

      bool error(false);

      try

         {

         to = from;

         }

      catch (...)

         {

         error = true;

         }

      return error;

      }

   T *value_;

   wrapper(wrapper const &);

   wrapper &operator=(wrapper const &);

   };

 

    (哇!52行,原来只有20行的!而且这还只是一个简单的例子。)

    注意,所有的异常处理函数只是吸收了那些异常而没有做任何处理。虽然这使得wrapper异常安全,却没有纪录下导致这些异常的原因。

    我在Part13中讲的在构造函数上的相冲突的原则在这儿同样适用。异常安全是不够的,并且实际上是达不到预期目的的,如果它掩盖了最初的异常状态的话。同时,如果异常对象在被捕获前就弄死了程序的话,大部分的异常恢复方案都将落空。最后,良好的设计必须满足下两个原则:

l         通过异常对象的存在来注视异常状态,并适当地做出反应。

l         确保创造和传播异常对象不会造成更大的破坏。(别让治疗行为比病本身更糟糕。)

 

1.4     其它说法

    在过去3部分中,我剖析了异常安全。我强烈建议你读一下这些文章:

l         The first principles of C++ exception safety come from Tom Cargill's "Exception Handling: A False Sense of Security," originally published in the November and December 1994 issues of C++ Report. This article, more than any other, alerted us to the true complexities and subtleties of C++ exception handling.

 

 

l         C++ Godfather Bjarne Stroustrup is writing an exception-safety Appendix for his book The C++ Programming Language (Third Edition) (http://www.research.att.com/~bs/3rd.html). Bjarne's offering a draft version (http://www.research.att.com/~bs/3rd_safe0.html) of that chapter on the Internet.

 

 

l         I tend to think of exception safety in terms of contracts and guarantees, ideas formalized in Bertrand Meyer's "Design by Contract" (http://www.eiffel.com/doc/manuals/technology/contract/page.html) programming philosophy. Bertrand realizes this philosophy in both his seminal tome Object-Oriented Software Construction (http://www.eiffel.com/doc/oosc.html) and his programming language Eiffel (http://www.eiffel.com/eiffel/page.html).

 

 

l         Herb Sutter has written the most thorough C++ exception-safety treatise I've seen. He's published it as Items 8-19 of his new book Exceptional C++ (http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0201615622). If you've done time on Usenet's comp.lang.c++.moderated newsgroup, you've seen Herb's Guru of the Week postings. Those postings inspired the bulk of his book. Highly recommended.

 

 

l         Herb's book features a forward written by Scott Meyers. Scott covers exception safety in Items 9-15 of his disturbingly popular collection More Effective C++ (http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=020163371X). If you don't have this book, you simply must acquire it; otherwise Scott's royalties could dry up, and he'd have to get a real job like mine.

 

Scott(在他的Item14)认为,不应该将异常规格申明加到模板成员上,和我的正相反。事实是无论用不用异常规格申明,总有一部分程序需要保护所有异常,以免程序自毁。Scott公正地指出不正确的异常规格申明将导致std::unexpected――这正是他建议你避开的东西;但,在本系列的Part11,我指出unexpected比不可控的异常传播要优越。

    最后要说的是,这儿不会只有一个唯一正确的答案的。我相信异常规格申明可以导致更可预知和有限度的异常行为,即使是对于模板。我也得坦率地承认,在异常/模板混合体上我也没有足够经验,尤其是对大系统。我估计还很少有人有这种经验,因为(就我所知)还没有哪个编译器支持C++标准在异常和模板上的全部规定。

0 0

相关博文

我的热门文章

img
取 消
img