`

C++,永久改变你写异常安全代码的方式(神奇的Loki::ScopeGuard)

    博客分类:
  • c++
阅读更多

 作者:Andrei Alexandrescu and Petru Marginean

原文地址:http://www.ddj.com/cpp/184403758

翻译,裁剪,修改:purewinter

转:http://blog.csdn.net/purewinter/article/details/1860875

注:裁剪修改只是为了让更多csdn上的读者不会因为此文太长而放弃阅读。。。

注2:Loki::ScopeGuard不仅对通常意义的异常有用,对于所有可以使用RAII的地方均有用。包括new出来的内存空间的管理,FILE或CFile之类的文件句柄等。

第一次翻译,不足之处多多指教。 



可能有异常出现的时候,编写正确的代码并不是一件简单的工作,这是我们都要面对的问题。异常导致了一个与程序主控制流几乎无关的控制流。因此,解决异常流的问题也就需要另外一种途径,以及另外一种工具。

 

编写异常安全代码很困难—— 一个普通的例子

(译注:原文这个例子介绍得很详细,此处将只说要点)假设一个用户管理中,可以为已登陆的用户添加好友。好友将添加至内存列表以及数据库。下面是部分源代码:

 

class  User
...
{
    ...
    
string  GetName();
    
void  AddFriend(User &  newFriend);
private :
    typedef vector
< User *>  UserCont;
    UserCont friends_;
    UserDatabase
*  pDB_;
}
;
void  User::AddFriend(User &  newFriend)
...
{
    
//  Add the new friend to the database
    pDB_ -> AddFriend(GetName(), newFriend.GetName());   // 语句1
    
//  Add the new friend to the vector of friends
    friends_.push_back( & newFriend);   // 语句2
}

 

对很多人来说会很吃惊,对于这个两行代码的AddFriend,却有一个致命的bug:如果内存不足导致语句2执行失败,数据库里就会有新好友的记录,而内存中没有——这种不一致是十分危险的。

一个很简单的解决方案就是,把语句1和语句2对调。这样语句2失败时将抛出异常,也就不会执行语句1了。问题是,如果数据库操作抛出异常了呢?这种 不一致性就更危险了。嗯,是时候质问那些写数据库代码的人了:“你们这些家伙,就不能返回个错误代码啊?为什么非要抛出异常啊?”那些家伙说了,“嗯,你 想,我们是构建在高可靠性的基于TZN网络的XYZ数据库服务器集群上的,所以失败是及其罕见的。既然如此罕见,我们认为最好用异常来表示处理失败,毕竟 异常只出现在异常情况下嘛( because exceptions appear only in exceptional conditions),对吧?”(译注:TZN和XYZ都是随你YY的名称)这似乎很有道理。但是你又不想让一个数据库异常让你的程序跌入混沌深 渊...你该怎么办呢? 实际上,你必须要执行两个操作,其中任何一个失败你都要回滚到什么都没做的状态。让我们看看几种实现的方法。

 

解决方案1:蛮干

很简单,加try-catch就是。

void  User::AddFriend(User &  newFriend)
{
    friends_.push_back(
& newFriend);
    
try
    
{
        pDB_
-> AddFriend(GetName(), newFriend.GetName());
    }

    
catch  (...)
    
{
        friends_.pop_back();
        
throw ;
    }

}

 

如果push_back失败了,那没关系,因为这样的话AddFriend不会执行。若AddFriend失败,那么会被catch,然后执行pop_back,最后漂亮地把异常重新抛出。嗯,这的确行得通。但是这样做也问题多多:

代码增加并且显得很笨拙。2行的代码变成了10行,而且这样及其令人反感:想象一下你的代码里到处是这样的try-catch.....

更严重的是,这样的代码很难扩展。想象一个有第三条语句要加进来。那将使代码变得更笨拙,(由于三条语句任意一条都可以失败,)你得写嵌套的try,或者自己写一种复杂的流控制标志和语句。(译注:我是不敢想象,因为我就写过,实在是痛苦。)

这种方法不仅使代码膨胀,效率低下,更严重的是是可读性变得很差,也难以维护。

 

解决方案2:原则上正确的途径

给任何一个真正熟悉C++的人说说,他们马上会说,“噢,你应该使用RAII(resource acquisition is initialization ) 来 解决这个问题。在失败的情况下让析构函数自动处理资源释放(或回滚)。”OK,让我们来试试。对于每一个你需要undo的操作,都需要相应的一个 class。这个class的构造函数执行那个操作,而析构函数回滚它,除非你调用了一个“提交”函数,告诉析构函数不要回滚操作。对于 push_back操作,可能的class代码如下:

class  VectorInserter
{
public :
    VectorInserter(std::vector
&  v, User &  u)
    : container_(v), commit_(
false )
    
{
        container_.push_back(
& u);
    }

    
void  Commit()  throw ()
    
{
        commit_ 
=   true ;
    }

    
~ VectorInserter()
    
{
        
if  ( ! commit_) container_.pop_back();
    }

private :
    std::vector
&  container_;
    
bool  commit_;
}
;

 

这其中最重要的可能就是在Commit函数定义旁的“throw()”描述符了。它指出了Commit操作永远会成功这个事实。而实际上Commit只是告诉VectorInserter:“一切正常,不要回滚任何操作。”你将这样使用这个类:

void  User::AddFriend(User &  newFriend)
{
    VectorInserter ins(friends_, 
& newFriend);
    pDB_
-> AddFriend(GetName(), newFriend.GetName());
    
//  Everything went fine, commit the vector insertion
    ins.Commit();
}

 

AddFriend现在有两个部分:做实际操作的部分,还有提交的部分。提交的部分不会发生异常:它只是阻止回滚而已。这种方法在任何情况下都工作 得很好。如果push_back操作失败,由于ins对象构建失败,自然下面的操作以及ins的析构函数都不会执行。(ins都没构建完毕,自然无所谓析 构)如果数据库操作失败,那么ins的析构函数将会执行pop_back。

这个方案看上去很不错,实际上工作得也很好,但在现实中却还是有一些麻烦。你得为※每个※需要回滚的操作额外写一个类,于是你的类列表里就多出了相 当多的这种类。重复的写这种类显然不是一种好主意,而且很容易出错——没注意到吗?VectorInserter就有一个bug:它的拷贝构造函数干了一 件很不好的事情。(天哪!那将会pop_back多次......)定义类本来就不是一件简单的事情,这也是不要写很多这种类的另一个理由。

 

解决方案3:普遍的现实

无论你看完了刚才所有的讨论或者根本就没看,你知道你最终的方案是什么?当然,你很清楚,就是这样:

void  User::AddFriend(User &  newFriend)
{
    friends_.push_back(
& newFriend);
    pDB_
-> AddFriend(GetName(), newFriend.GetName());
}

 

这是一种建立在并不科学的论据的基础上的方案:“谁说内存不足了?这里还有狗X的一半多呢!”“就算内存用光了,不是还有内存分页机制会使程序变成 蜗牛的速度来避免程序崩溃吗!”“那些搞数据库的家伙说了,那个AddFriend数据库操作几乎不可能失败!他们可是用了XYZ和TZN!”“这根本不 值得烦恼。我们会在以后的review中再解决。”于是,最终代码就成了这样。随着时间的流逝以及日程压力,那些本来只在“理论”上的问题开始浮现,而你 却不知道它是由于硬件问题还是由于异常。随着用户数量的增加,你的程序逐渐耗尽内存,你的网络管理员可能因为性能抖动太大而关闭分页机制,你的数据库可能 变得不那么可靠.....而你对此没有任何准备。

 

解决方案4:Petru的办法(Loki::ScopeGuard)

用Loki::ScopeGuard,你可以轻松,正确,高效地写出代码:

void  User::AddFriend(User &  newFriend)
{
    friends_.push_back(
& newFriend);
    ScopeGuard guard 
=  MakeObjGuard(friends_,  & UserCont::pop_back);
    pDB_
-> AddFriend(GetName(), newFriend.GetName());
    guard.Dismiss();
}

 

guard做的唯一工作就是当它离开它的作用范围时调用friends_.pop_back,除非你调用了Dismiss(如果那样,guard就 什么也不做)。ScopeGuard实现了在它的析构函数里自动对函数或成员函数的调用。(译注:看到RAII方法的缺陷时就应该要想到,ScopeGuard其实就是通用的RAII方法的实现。 因此,它有RAII的一切优点,并且避免了其缺点。)

你将这样使用ScopeGuard:如果你有一些操作需要“要么全做,要么都不做”(原子性),那就在每一个操作后面放一个ScopeGuard。在全部完成以后,再全部提交。(提交是不会异常的,因此对提交顺序没有要求)

ScopeGuard对普通函数同样有用(注意上面的例子是对类的成员函数):

void *  buffer  =  std::malloc( 1024 );
ScopeGuard freeIt 
=  MakeGuard(std::free, buffer);
FILE
*  topSecret  =  std::fopen( " cia.txt " );
ScopeGuard closeIt 
=  MakeGuard(std::fclose, topSecret);


(译注:上面的普通函数的例子和前面的异常安全的例子还有不同:上面的例子是解决“释放资源”,而异常安全的例子是为了“自动回滚”。其实,ScopeGuard真正是适用于任何需要RAII情况 ,反而不是适用于任何需要异常安全情况 。另外,由于资源是肯定要释放的,所以基本上不会Dismiss。也就可以用下面的宏:

{
    FILE
*  topSecret  =  fopen( " cia.txt " );
    ON_BLOCK_EXIT(std::fclose, topSecret);
    ... use topSecret ...
}
  //  topSecret automagically closed

关于ScopeGuard于异常安全的其他讨论,我可能会新开一贴。)

如果所有操作都成功了,你将Dismiss所有操作。否则,每一个成功构建的ScopeGuard将自动调用你初始化时给它的函数。这样你就不必为 了pop_back,关闭文件等undo操作写一个专用的类。这使得ScopeGuard成为一个很有用的轻松的写异常安全代码的可重用工具。(译注:如 果一个undo操作要执行一系列函数,Loki有MultiMethods。但是若对应不到一个函数.....就要自己手写了。这使我想到Java里的匿 名函数...要是C++能支持多好。)

 

使用注意

(译注:为了照顾大多数国人的习惯,我把这个从文章最后移了上来并做了修改,否则估计很多人会无视它。)
你应该像它本意一样使用它:当做函数里的变量。你不应该把它用做类的成员变量,不应该把它放到vector里去,不应该在堆上创建它 。(如果你要这么做,应该使用Janitor类,但这会导致一些性能损失。)

另外,像在下文里提到的,虽然ScopeGuard中有防范措施,但最好不要传入一个可能抛出异常的回滚操作 。毕竟,回滚的时候失败了,那该怎么办?(所以说ScopeGuard并不适用于任何异常安全情况。)

 


实现ScopeGuard

(译注:以下内容涉及C++ 模版知识,还不清楚的请复习一下:C++ Primer,C++ Templates,Effective STL随你挑一本看看吧。)

 ScopeGuard是RAII的一种泛化实现。它与RAII的不同是ScopeGuard只关注清理的部分——资源申请你来 做,ScopeGuard帮你清除。清理(回收)资源有很多办法,如调用一个函数/仿函数,调用一个对象的成员函数。它们都可能需要0个,1个或多个参 数。自然的,我们建立了一个类的继承体系来处理这种差异。在这个继承体系的对象的析构函数来做实际的工作。而这个继承体系的基 类,ScopeGuardImplBase,定义如下:

class  ScopeGuardImplBase
{
public :
    
void  Dismiss()  const   throw ()
    
{    dismissed_  =   true ;    }
protected :
    ScopeGuardImplBase() : dismissed_(
false )
    
{}
    ScopeGuardImplBase(
const  ScopeGuardImplBase &  other)
    : dismissed_(other.dismissed_)
    
{    other.Dismiss();    }
    
~ ScopeGuardImplBase()  {}   //  nonvirtual (see below why)
    mutable  bool  dismissed_;

private :
    
//  Disable assignment
    ScopeGuardImplBase &   operator = (
        
const  ScopeGuardImplBase & );
}
;

 

ScopeGuardImplBase管理dismissed_标志,而它决定子类是否执行清除操作。注意到,我们的析构函数并没有使 用"virtual"关键字。控制住你的好奇心,我们有一个好方法来获得多态行为却不需要virtual关键字。(译注:噢,他说的是多态行为,而不是析 构函数,虽然这个“多态”的确是针对析构函数的。这里用protected来保证这东西不会被用户代码胡乱的析构。当然,如果你非要继承它然后自己胡乱析 构。。。那应该由你自己负责。)至于现在,让我们看看我们怎样实现一个对象:它会在析构时调用一个只有一个参数的函数或仿函数,并且如果调用 Dismiss方法,它在析构时不做任何事。

template  < typename Fun, typename Parm >
class  ScopeGuardImpl1 :  public  ScopeGuardImplBase
{
public :
    ScopeGuardImpl1(
const  Fun &  fun,  const  Parm &  parm)
    : fun_(fun), parm_(parm) 
    
{}
    
~ ScopeGuardImpl1()
    
{
        
if  ( ! dismissed_) fun_(parm_);
    }

private :
    Fun fun_;
    
const  Parm parm_;
}
;


为了能方便地使用ScopeGuardImpl1,我们定义一个辅助函数:

template  < typename Fun, typename Parm >
ScopeGuardImpl1
< Fun, Parm >
MakeGuard(
const  Fun &  fun,  const  Parm &  parm)
{
    
return  ScopeGuardImpl1 < Fun, Parm > (fun, parm);
}

就像STL里make_pair和bind1st等等一样,这种辅助函数使你不必输入模版参数。实际上,你不必显式地创建一个ScopeGuardImpl1对象。还在奇怪我们如何实现多态行为却不需要virtual的吗?OK,让我们看看ScopeGuard的定义吧:

typedef  const  ScopeGuardImplBase &  ScopeGuard;


令人惊奇的是,它只是个typedef。现在让我们解开这个谜团。根据C++标准,一个由临时变量定义的引用,将导致改临时变量的生命周期延长至和此引用一样长。 还是用一个例子来说明吧。如果你写下下面代码:

FILE *  topSecret  =  std::fopen( " cia.txt " );
ScopeGuard closeIt 
=  MakeGuard(std::fclose, topSecret);

那么MakeGuard将会生成如下类型的一个临时变量:

ScopeGuardImpl1 < int  ( & )(FILE * ), FILE *>


然后这个临时变量将会被赋值给你定义的引用类型的常量closeit。本来这个临时变量的生命周期到此结束。但是由于上述标准的规定,这个 临时变量的生命周期被延长了。于是,在closeit退出作用范围时,临时变量进行析构——自然这时调用的是正确的析构函数。(译注:这是因为并非由 closeit来调用析构函数,只是closeit生命结束时临时变量同时进行析构而已。的确是巧妙的多态。但是,若基类的析构函数不是 protected,则用户代码将可能进行错误析构。)在这里,析构函数将关闭打开的文件。


ScopeGuardImpl1支持有一个参数的函数/仿函数。很容易写出类似的支持有0个,2个,3个等等参数的函数的实现 (ScopeGuardImpl0,ScopeGuardImpl2,ScopeGuardImpl3...)。如果你完成了这些,那么可以简单的实现 MakeGuard的重载,比如:

template  < typename Fun >
ScopeGuardImpl0
< Fun >
MakeGuard(
const  Fun &  fun)
{
    
return  ScopeGuardImpl0 < Fun  > (fun);
}

...

到现在我们已经完成了所有对类C API界面的函数支持,并且没有使用虚函数。让我们再接再厉... 

 

让ScopeGuard 支持类成员函数

下面该加入对类成员函数的支持了。(译注:研究过funtor的人应该知道,不过是对付operator.*和operator->*而已, 更何况这里不需要更复杂情况的支持。)其实一点也不困难,让我们实现ObjScopeGuardImpl0,让它支持需要0个参数的类成员函数。

template  < class  Obj, typename MemFun >
class  ObjScopeGuardImpl0 :  public  ScopeGuardImplBase
{
public :
    ObjScopeGuardImpl0(Obj
&  obj, MemFun memFun)
    : obj_(obj), memFun_(memFun) 
    
{}
    
~ ObjScopeGuardImpl0()
    
{
        
if  ( ! dismissed_) (obj_. * fun_)();
    }

private :
    Obj
&  obj_;
    MemFun memFun_;
}
;


除了使用成员函数指针那里的古怪语法,其他没什么特别。让我们看看该怎么实现MakeObjGuard:

template  < class  Obj, typename MemFun >
ObjScopeGuardImpl0
< Obj, MemFun, Parm >
MakeObjGuard(Obj
&  obj, Fun fun)
{
    
return  ObjScopeGuardImpl0 < Obj, MemFun > (obj, fun);
}


还是没什么区别。再看看怎么使用:

ScopeGuard guard  =  MakeObjGuard(friends_,  & UserCont::pop_back);


注意那个"&"。这次我们传进去的是成员函数的指针,所以需要一个取址操作符。 而MakeObjGuard将返回一个具有如下类型的临时变量:

ObjScopeGuardImpl0 < UserCont,  void  (UserCont:: * )() >


幸运的是,如同MakeGuard,并不需要我们来输入一个如此奇怪的类型。就这样,对成员函数的支持也完成了,与对普通函数的支持区别不大。

 

错误处理

 你应该清楚,类的析构函数是绝对不能(must not) 抛出异常的。如果一个类的 析构函数抛出异常,将导致未定义的行为。(译注:也就是什么事都可能发生,包括你的程序啪地就没了。至于你的电脑会不会啪地......那得看编译器、操 作系统和硬件了。......喂,我说的是啪地就黑了,不要想歪了。)由于ObjScopeGuardImplX和ScopeGuardImplX的析构 函数调用的都是用户提供的函数,而它们是有可能抛出异常的。在理论上,你不应该把可能抛出异常的函数传给MakeGuard或MakeObjGuard, 在实际上,析构函数有如下的保护:

template  < class  Obj, typename MemFun >
class  ObjScopeGuardImpl0 :  public  ScopeGuardImplBase
{
    ...
public :
    
~ ScopeGuardImpl1()
    
{
        
if  ( ! dismissed_)
            
try   { (obj_. * fun_)(); }
            
catch (...)  {}
    }

}

(译注:而在现在的版本,这个try-catch是放到Base的SafeExecute函数中去了。如下:)

// 在Base中加入此成员模版函数:
template  < typename J >
        
static   void  SafeExecute(J &  j)  throw () 
        
{
            
if  ( ! j.dismissed_)
                
try
                
{
                    j.Execute();
                }

                
catch (...)
                
{}
        }


// 在子类中使用如下代码:
~Obj ScopeGuardImpl0()  throw () 
        
{
            SafeExecute(
* this );
        }


        
void  Execute() 
        
{
            fun_();
        }


不过,不管怎样,使用不会抛出异常的函数才是最好的。

 

 

支持引用传参

 到现在我们都很开心地使用ScopeGuard,直到我们被下面这个问题困住了:

void  Decrement( int &  x)  -- x; }
void  UseResource( int  refCount)
{
    
++ refCount;
    ScopeGuard guard 
=  MakeGuard(Decrement, refCount);
    ...
}


上面的guard对象保证了refCount的值将被保存直到退出UseResource。不管这个想法是否有用,上面的代码并不起作用。 问题是,ScopeGuard保存了refCount的一个拷贝。(见ScopeGuardImpl1的定义)而现在我们需要保持refCount的一个 引用,这样Decrement才能操作它。一种解决方案是实现额外的类,不过这将导致大量重复。并且如果你遇到多个变量,有的要引用有的不需要,那将十分 麻烦。我们依然使用小巧的辅助类来解决这个问题:

template  < class  T >
class  RefHolder
{
    T
&  ref_;
public :
    RefHolder(T
&   ref ) : ref_( ref {}
    
operator  T &  ()  const
    
{
        
return  ref_;
    }

}
;
template 
< class  T >
inline RefHolder
< T >  ByRef(T &  t)
{
    
return  RefHolder < T > (t);
}



RefHolder和它的辅助函数ByRef是很精巧的。它们无缝的将引用适配成一个值,并允许ScopeGuardImpl1和引用一起工作而不需要任何改动。(译注:并且在最后用户函数调用时又会把引用传给它。)而你只需要把你的引用交给ByRef来包装,如下:

void  Decrement( int &  x)  -- x; }
void  UseResource( int  refCount)
{
    
++ refCount;
    ScopeGuard guard 
=  MakeGuard(Decrement, ByRef(refCount));
    ...
}



我们发现这个解决方案是十分有表现力和创见的。最棒的是那个在ScopeGuardImpl1中用到的"const"修饰符。相关部分摘录如下:

template  < typename Fun, typename Parm >
class  ScopeGuardImpl1 :  public  ScopeGuardImplBase
{
    ...
private :
    Fun fun_;
    
const  Parm parm_;
}
;


这个小小的const是十分重要的。它防止了使用non-const引用而导致的编译和运行错误。换句话说,如果你忘记使用ByRef,编 译器会向你抱怨而拒绝工作。(译注:当然,这要求你的函数接受的就是一个引用参数。如果你提供的函数不是接受引用参数,那你就可以传non-const变 量或non-const引用给它。这才是它的精巧之处。)

 


等等,还有更多。。。

现在你拥有了编写异常安全代码的所有需要的东西,不必再为此烦恼了。不过,有时候你需要ScopeGuard永远在你退出(定义它)的语句块时都执 行。在这种情况下,再声明一个ScopeGuard变量显得有些累赘——你只需要一个临时变量,一个没有名字的临时变量。这个时候你就可以使用 ON_BLOCK_EXIT宏。

{
    FILE
*  topSecret  =  fopen( " cia.txt " );
    ON_BLOCK_EXIT(std::fclose, topSecret);
    ... use topSecret ...
}
  //  topSecret automagically closed

  ON_BLOCK_EXIT声称:“我希望在当前块退出时执行这个操作。”类似的,ON_BLOCK_EXIT_OBJ为类成员函数实现了类似的功能。

这两个宏使用了非传统(虽然合法)的宏技巧,这种技巧将不公开(译注:也不特别,没必要不公开吧。)对它们感到好奇的人可以到源代码中找到它们。

 

在真实世界中的ScopeGuard

可能ScopeGuard最棒的地方就是它的容易使用和概念简单了。这篇文章详细地介绍了整个实现,不过介绍ScopeGuard的使用方法只用了 一小部分时间。在我的同仁中,ScopeGuard像野火般传播开去。每个人都把ScopeGuard当作一个对很多情况都很有用的工具,无论是无序返回 或者异常。在ScopeGuard的帮助下,你最终可以轻松地编写异常安全代码,并且也能轻松地理解和维护它。

 

 


 

后记:

上述的代码在VC6中可以运行(但不能同RefHolder一起),但是不能在VC8中运行。原因是MakeGuard函数自动推导模版参数失败: 不能从重载函数到重载函数进行参数推导。而目前Loki的代码已改正这个问题,就是在每个ImplX里加入static的MakeGuard模版函数,而 全局MakeGuard模版函数制定使用的类名。相关修改如下:

 template  < typename F, typename P1 >
    
class  ScopeGuardImpl1 :  public  ScopeGuardImplBase
    
{
    
public :
        
static  ScopeGuardImpl1 < F, P1 >  MakeGuard(F fun, P1 p1)
        
{
            
return  ScopeGuardImpl1 < F, P1 > (fun, p1);
        }

   ....
  }
;

// 对应的全局MakeGuard模版函数:
template  < typename F, typename P1 >  
    inline ScopeGuardImpl1
< F, P1 >  MakeGuard(F fun, P1 p1)
    
{
        
return  ScopeGuardImpl1 < F, P1 > ::MakeGuard(fun, p1);
    }


具体原因尚不清楚。似乎是由于构造函数有重载,所以导致推导失败,而指定调用类中的一个函数以后,由于后者没有重载(只有模版参数),所以推导成功。

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics