技巧和窍门–何时进行ASSERT或不ASSERT…

就是那个问题。断言的使用通常甚至使最有经验的开发人员也感到困惑。开发人员应考虑要传递给ASSERT的表达式是潜在的错误情况,还是试图捕获错误。这种情况下的错误是应由软件处理的运行时条件。断言是关于给定时间点的系统状态的假设,如果不正确,则意味着软件中存在错误。

以下面的代码段和声明为例:

2015年08A2F1

在以上代码段中,允许的系统状态在枚举中定义。应用程序代码使用函数System_StateSet来设置系统状态。当前编写的函数不会对函数的输入或输出进行任何检查,这些输入或输出是使用断言的主要候选对象。请记住,应该使用断言来查找代码中的错误,而不是捕获错误情况。将SystemState_t以外的任何其他内容传递给System_StateSet都不是错误,而是一个错误!该BUG应该是固定的。考虑到这一点,可以将System_StateSet重写如下:

2015年08A2F2

在开发过程中,如果代码中存在允许SystemState超过SYSTEM_MAX_STATE的错误,则声明将捕获该错误。以这种方式使用断言是完全合适的,尤其是在设置系统状态由应用程序代码而非用户输入控制的情况下。用户输入属于运行时错误类别,并且应该捕获错误而未声​​明。

现在让我们考虑另一个简短的示例,其中断言是不合适的。检查以下代码段:

2015年08A2F3

在上面的示例中,文件以只读模式打开。如果文件成功打开,则FileHandle符号应为非零。该断言用于确保FileHandle不为零,否则将触发该断言。问题在于文件Test.txt是否存在于文件系统上很可能与用户完全相关。与其在文件不存在或无法打开时触发断言,不如以运行时错误捕获的方式处理该断言。

断言的最佳定义(我已经能够找到)是“断言是程序中特定点的布尔表达式,除非程序中存在错误,否则它将是正确的。”记住该定义,并使其成为使用断言或运行时错误陷阱的适当指南。

发表评论

您的电子邮件地址不会被公开。 必需的地方已做标记 *

该网站使用Akismet减少垃圾邮件。 了解如何处理您的评论数据.