C++ Coding Standards:错误处理和异常

By Herb Sutter, Andrei Alexandrescu 著

 

树人 译

 

错误处理和异常

 

68.      使用断言(assert)来证明内部假设和不变量。

 

Be assertive！对一个模块的内部假设可以使用assert或等价物来说明（例如：调用者和被调用者由同一个人或团队维护），这个假设必须总为true，否则就代表着程序设计错误（例如：函数调用方发现违反了一个函数的前置条件）。（参见：Item70）要确保断言不会产生副作用。

 

69.      形成一个合理的错误处理策略，并且严格地遵守。

 

Consciously specify, and conscientiously apply, what so many projects leave to ad-hoc (mis)judgment：在设计前期开发一个实用，一致与合理的错误处理策略，比把它坚持下来。确保它包括：

 

l          标识：什么条件式是错误。

 

l          严重性：每个错误的重要度和紧急度。

 

l          检测：哪段代码负责检测错误。

 

l          传播：在各个模块中报告和传播错误通知的机制。

 

l          处理：什么代码负责对错误做些什么。

 

l          报告：错误将如何被记录或通知用户。

 

只在模块边界上改变错误处理机制。

 

70.      区别错误和无错误（errors and non-errors）。

 

违约就是一个错误：函数是一个作业单元。因此，函数失效应该被看成一个错误或者其它基于它们对函数的影响的东西。在一个函数f中，当且仅当违反了函数f的前置条件或阻止f满足它的被调用者的任何一个前置条件，完成f自身的任何一个后置条件，或者是重建f负责维护的任何一个不变量时，失效才是一个错误。

 

特别的在此处我们把内部程序设计错误除外（例如在一个模块内，调用者和被调用者是同一个人或团队），这是和使用断言相关的一个独立的范畴。

 

71.      设计和编写错误安全（容错）代码。

 

许诺，但不能惩罚：在每个函数中，提供最强壮的安全性来保证使不需要惩罚的调用者免受惩罚。至少要提供基本的保证。

 

确保错误能把程序置于一个有效的状态。这就是基本的保证。注意不变量破坏invariant-destroying（包括不局限于泄漏），它们只是普通的错误。

 

优先增加对“操作的最终状态不是初始状态（如果有错误发生，操作是可以回滚）就是指定的目标状态（如果没有错误发生，操作就是所承诺的）”的保证。这是强保证（strong guarantee）。

 

优先增加对“操作不可能失败”的保证。尽管对大多数函数来说，这是不可能的，但这是诸如构造和析构函数所要求的。这是no-fail保证。

 

72.      优先使用异常来报错。

 

当你受伤时，就抛出异常吧：优先使用异常来报错，而不是通过错误代码。当异常不能用（参见：Item62）和条件式不是错误的时候，可以对错误使用状态代码（例如：返回代码，errno）。当恢复操作不可能或不需要时，可以使用诸如优雅或不优雅的终止等方法。

 

73.      以传值来抛出异常，以传引用来捕获异常。

 

适当地了解catch语句：以传值（非指针）方式来抛出异常并通过传引用（通常是const）来捕获异常。这是和异常语义极好地交错的结合。当重新抛出同一异常时，优先使用throw;，而不是throw e;。

 

74.      适当地报告，处理和解释错误。

 

Know when to say when：在错误被探查到并被标识为错误时报告错误。在最近的一级可以正确处理错误的地方处理和解释各个错误。

 

75.      避免异常规约。

 

Take exception to these specifications ：不要为你的函数编写异常规约，除非你被强迫去做（因为其它你不能变更的代码已经介绍过它们了；参见： Exception ）