C++的另一种错误处理策略

这篇短文是讨论一个大多数程序员都感兴趣的一个话题:错误处理。错误处理是编程的一个“黑暗面”。它既是应用程序的“现实世界”的关键点,也是一个你想隐藏的复杂业务。

在早期的C编程生涯中,我知道三种错误处理的方式。

C语言的方式:返回错误码

C语言风格的错误处理是最简单的,但是并不完美。

C语言风格的错误处理依赖于“当程序遇到错误时返回一个错误码”。这里是一个简单的例子:

使用这种方式的有什么好处?

你可以在调用函数之后直接处理错误码(在C语言中,你也会这样处理),显示一个错误消息或者直接终止程序。或者仅仅恢复程序最近的一个状态,终止计算。

当你找不到错误处理在哪里的时候,你只需要后头看看函数调用,错误处理就在那个附近。

使用这种方式有什么不好?

有人可能会告诉你,这种异常/错误处理方式和“执行逻辑”混在了一起。当你顺序地阅读这些代码的时候就行程序执行一样,你看到了一会错误处理,一会程序执行。这样很糟糕,你可能更喜欢只读程序执行逻辑或者错误处理逻辑。

并且你被限定使用错误码,如果你想要提供更多的信息,你需要创建一些功能函数比如:errstr或者提供全局变量。

使用C++的方式

C++作为对C的增强,引入了一种新的错误处理方式——异常。异常通过抛出一个错误的方式来中断正常代码执行逻辑,并可以被其他地方所捕获。下面是一个简单的例子:

这样做的好处?

程序逻辑和错误处理分离了。一边你可以看到函数是如何工作的,而另一边你可以看到函数失败时候是怎么处理的。这样做很完美,可以很容易看出错误处理和正常程序逻辑。

另外,现在你可以为你的错误提供你需要的尽可能多的信息,因为你可以将需要的内容填充在自定义异常对象里。

这样做的坏处

编写详尽的异常处理变得很冗。你需要一个异常树,但是最好不要太大,这样,你可以选择捕获感兴趣的异常。同时,内部需要提供错误码,来获知究竟发生了什么,同时需要检索一些错误消息,等等。编写写异常类通常都是冗长,这是将信息嵌入到错误里来灵活处理更多的信息的成本。

这里的错误处理哲学是将错误尽可能推迟到需要处理的地方再处理,当你不知道程序执行过程究竟哪里会产生一个错误,你需要跳过不同的文件和功能函数来查找,这通常都是困难的,如果你在一个很深的调用树(这里意思是当你将函数调用绘制出一个图形,其形状类似一棵树)上引发了一个异常,你需要指定在哪里来处理这个异常,当它被处理的时候,它又是在哪里发生的。特别是当你的程序很大,又是很早之前编写,有恰巧设计不够良好的时候,就更加显得困难。而大多数商业项目都是这样。

所以我觉得“异常是危险的”。虽然它提供了一种良好的方式来处理错误——仅限于一些小项目,并且这里的调用图简单且易于掌握时候。

错误封装的模式

我这里把它叫做一种模式,所以人们不必害怕担心。后面,我会给它一种更好的命名,所以请不要着急。

错误封装的主旨是创建一种封装来包含错误消息或者错误的返回值。我们通常会选择字符串而不是其他,因为这也并不容易实现。我们尽力保证语法的可读性,可理解,并且容易应用。我们不处理拷贝构造或者多参数函数及返回值,这里仅给出一个尽可能简单的例子。

让我们以下面的例子开始:

乍一看,这里有点类似C语言的风格,但是不是,为表明这一点,请看接下来的多个函数调用例子:

好了,这里发生了什么?bind是一个成员函数来绑定你的函数调用,试着去应用它。如果错误装箱里面含有一个值,那么它就应用于函数调用,继续返回一个错误装箱(编译器不允许你返回一个不带错误装箱的函数)。

所以,我们链式调用了find_slashe,do_some_arithmetic, format和display.它们都不处理错误装箱,由于bind函数的作用,我们将函数E<something_out> f(something_in)返回结果给E<something_out> f(E<something_in>)函数做参数。

这里的好处是什么?

再一次,函数逻辑(调用链)和错误处理分离了。和异常一样,我们可以简单读一下函数调用链来了解代码逻辑,而不用关心执行是在哪里被中断的。事实上,函数调用链可以在任何调用时被中断。但是我们可以认为没有错误发生,如果我们的逻辑是正确的,可以很快速检查。

当然,类型推导会阻止你在调用display之后继续进行绑定。所以我们也没有失去类型能力。

注意,我们没有在其他地方调用这些函数,我们在最后将这些方法组装在一起。这里是关键,你应该编写一些小的模块函数(另外,注意:你应该编写模板函数使其工作)接收一个值,然后计算一个新值或者返回失败。在每一步中,你都不需要考虑可能出现错误导致你的控制流中断,并且校验你是否在一个有效的状态上(异常安全基于查询每个函数调用,指出函数是否中断你的控制流程,如果出现异常会发生什么),基于这一点,这样做更安全。

和异常一样,我们可以处理很详细的信息,尽管这里我们编写的是一个偏模板函数,所以也容易理解一些。

我们可以很容易放置异常处理逻辑,把它放在函数调用链之后(除非这个返回值还需要进一步被链接)。现在,我们有一个大的的执行流,没有中断,使用小的函数处理流程,容易定位。当需要添加一个新的错误时,你只需找到那些函数,通过函数调用链,你可以直接定位到处理位置,并根据需要添加。大型项目变得更加的线性化,并且更易读。

这样做有什么不足?

首先,这是一个新的处理方式,并且和C++的方式不兼容。这不是一个标准处理方法,当你使用stl时,你仍然需要使用异常。

对于我来说,这样做还是有点冗长。需要显式编写fail<int>(…)的模板推导显得有点怪异,如果你有个多态错误类型就更糟了,你不得不这样写fail<return_type, error_type>("...").

当函数有多个参数时编写也很困难,在其他一些语言中,可以使用适用类型和抽象类型很好地解决这个问题,不过这在C++中不会提供。我想更适合使用bind2(E<a>, E<b>, f)bind3(E<a>, E<b>, E<c>, f),可变模板参数功能更有用。

为获取封装错误中的值,我们需要检查这个值是否是有效值,接着调用一个“to_value”方法。我们没办法不通过检查来做到这一点。我们希望的是“解构”一个对象,不过这在C++中不支持,这也不是一些可以说“我们把它加入到下一个标准”的特性。

目前为止,我不知道读者是否有方法将其适配到成员函数中,如果你有想法,请测试一下,如果可以,请告知我们。

实现原子错误处理

我实现了它,我定义了这个黑魔法的名字——“原子化”,你可以认为“原子化”是一个对值和错误上下文的装箱,比如,一个box包含一个值或者什么也不包含是一个原子组(这里作为一个练习,你可以试着实现一下)。

有点奇怪的是,从某个角度来说队列是一个原子组,他们拥有一个上下文的值。

让我们从上面的E模版类实现开始,这里使用了C++11标准中的decltype和auto -> decltype类型,允许自动推导得到表达式的类型,这非常有用。

这里的bind函数有点怪异,但是他实现了我刚才提到的内容。

这里,我重载了<<运算符,所以导出装箱中的内容更容易一些。我们并不是一定需要它,在“真”值时去掉这一点也更好一些。

这里的例子,我们需要一个“E<void>”类型,但是它可能不一定使用。我们需要为void实现一个特别的重载,这里其实也是一样的,只不过期望的值是一个“空箱”。

我们没有提到ret和fail方法,事实上,它们只是对xxx::fail和xxx::ret函数的封装。

这里,你可以编译并执行一下上面的代码。

如果你想要更多的,可以试试下面这个更具体一点的例子:

3 收藏 3 评论

关于作者:周昌鸿

IT工作者,程序员,业余诗人,半宅男 (新浪微博:@双尾) 个人主页 · 我的文章 · 4

相关文章

可能感兴趣的话题



直接登录
最新评论
  • 使用大量模板,增加编译时间,增大程序体积

  • Michael   2014/03/01

    将错误码封装在对象里,为什么我就没想到。

  • anthonyhl   2014/04/16

    这个做法能称为增强表达能力的返回值方式,但并没有在返回值方式上有什么突破。
    返回值的问题在于它每个调用层都需要检查错误,而不只是链式调用,后者只是一个特殊情况。

跳到底部
返回顶部