c++异常处理第四篇---不使用try catch语句，使用Loki::ScopeGuard

转载：神奇的Loki::ScopeGuard 2011-07-05
12:52:05

分类： C/C++

转载：http://blog.csdn.net/fangqu/article/details/4242245

----------------------------------------------------------------------------------------

作者：Andrei Alexandrescu and Petru Marginean

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

翻译，裁剪，修改：purewinter

注：裁剪修改只是为了让更多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 isinitialization)来解决这个问题。在失败的情况下让析构函数自动处理资源释放（或回滚）。”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(...)

                {}

        }



//在子类中使用如下代码：

~ObjScopeGuardImpl0() 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);

    }

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