7基于契约编程实践.pptVIP

Design by Contract — Practice Language Support in C/C++ 和其他语言相比，C/C++特别注重效率，因此不受任何程序员控制的运行期内部检查机制 如：指针检查、数组下标检查、运行期类型检查等 断言的使用（非关键字） assert ASSERT assert()用法 assert宏的原型定义在assert.h中，其作用是如果它的条件返回错误，则终止程序执行 一般在Debug版有效，在Release版不起作用 用法： 在函数开始处检验传入参数的合法性 每个assert最好只检验一个条件 不要使用有副作用的语句 assert和后面的语句应空一行,以形成逻辑和视觉上的一致感 有的地方,assert不能代替条件过滤 例子 double sqrt(double x) { assert( x=0 ); //pre-condition //.... //.... //.... assert( fabs(y*y-x) eps ); //post-condition return y; } ASSERT和VERIFY 在VC环境下一般使用ASSERT和VERIFY 在Debug模式下作用基本一致，二者都对表达式的值进行计算，如果值为非0，则什么事也不做；如果值为0，则输出诊断信息。 在Release模式下效果完全不一样。ASSERT不计算表达式的值，也不会输出诊断信息；VERIFY计算表达式的值，但不管值为0还是非0都不会输出诊断信息。 因为 VERIFY() 违反了断言的思想，不能使程序代码和调试代码完全分离，最终可能会带来很多麻烦。因此，建议尽量少用不用这个宏。 Assert方式的缺点 不能直观地掌握出错地点 不能被捕获和重新处理 出错时不一定要中止，可能上层调用能够解决 如打开文件 在Debug版对性能有一定影响 Language Support in Java Preconditions Postconditions Class Invariants Language Support in Eiffel的例子 Effiel运行时检查 提前崩溃原则 尽早在错误点崩溃 便于发现错误 便于定位错误 不回避错误，避免鸵鸟态度 前置条件和后置条件处进行检查 断言与单元测试 错误和异常 错误 Error 应该预料到，一般能在调用的上一级解决 函数调用返回值检查 系统调用状态检查 异常Exception 不能预料原因 如无法打开必须的文件 网络传输错误 通常无法在本地解决，以至于不能预计会在调用层次的哪一级（直到用户交互）解决 严重失效Fault 不能预料出现，而且可能在任何地点出现 内存溢出 外部硬件错误 通常无法在程序内解决 异常处理 非结构化异常处理 If … then 就地处理 结构化异常处理 throw try … catch 可以以类的方式定义异常的类别和层次 重新审视DbC 调用者（应用程序等）和被调用者（库函数、组件库等）是平等的，都有权利和义务的说明。 检查前置条件是一种权利；而传统上模块中检查错误被认为是一种义务 If (pointer == NULL)… assert(pointer != NULL) 当出现错误，也就是契约（特别是前置条件）遭到破坏时，通常需要先检查调用者 重新审视DbC 明确错误和异常的关系 契约遭到破坏，是一种错误 满足前置条件下，无法正常得到结果，是一种异常，需要抛出 设计接口必须设计契约 尽可能将环境在准备好，然后传递给被调用者 * assert Expression1; assert Expression1 : Expression2 ; 语法: Expression2 can be any primitive type 从J2SE1.4之后，Java提供一些断言的支持，使用assert保留字 Expression1 must have type boolean or a compile-time error occurs. enabled or disabled 两种形式的 assert. e.g. it could serve as a unique integer code for the assertion Semantics: If assertions are disabled in a class, the assert statements contained in that class have no effect. If assertions are enabled, Expression1 is evaluated: — If it evaluates to false, an As