编程过程中的错误处理

[思路记录，不成文]

针对外部代码进行防御性编程

连自己都不相信，没人能写出完美的代码，包括自己，针对自己的代码进行防御性编程。

1. 程序出问题时终止程序。

2. 用Assert确保不可能发生的事情不会发生

3.异常留给异常情况

结论：防御性编程要进行，但没必要全面铺开，可以：

1. 另外利用一些工具来做辅助会轻松、清晰很多。DBC的语言支持，OVal类似的库支持。

2. DBC契约式设计，不处理不满足先验条件的情况(需要作输入减查不满足就返回，不提供服务。)

3.  Erlang Let it crash. 如果进程没有副作用，那么你根本不用关心进程为什么崩溃，因为你可以重启它.(需要一些支持，比如Erlang的变量单次赋值。)

DBC 契约式设计 （DBC）

在面向对象程序设计中一个类的函数提供了某种功能，那么它要：

期望所有调用它的客户模块都保证一定的进入条件：这就是函数的 先验条件—客户的义务和供应商的权利，这样它就不用去处理不满足先验条件的情况。

保证退出时给出特定的属性：这就是函数的 后验条件—供应商的义务，显然也是客户的权利。

在进入时假定，并在退出时保持一些特定的属性：不变式。

契约就是这些权利和义务的正式形式。我们可以用“三个问题”来总结DbC，并且作为设计者要经常问：

它期望的是什么？

它要保证的是什么？

它要保持的是什么？

OVal OVal is a pragmatic and extensible validation framework for any kind of Java objects (not only JavaBeans).  http://oval.sourceforge.net/

DBC http://softwarepractitioner.org/translations/meyer/contract.shtml

一个异常情形是 指一个软件单元不能履行它的契约，这可以有多种原因：发生硬件故障，调用的一个例程失败， 或有软件错误使得它不能完成契约。

在这样的情形下，只有三种处理方式有意义：

1. 再试：有可替换的策略可用。程序将恢复不变条件，然后用新的策略再试试。

2. 忙而不乱（organized panic）: 无可替换的策略可用。则恢复不变条件，终止， 然后产生一个新的异常情形来向调用者报告这个失败。

3. 假警报：事实上，如果采取一些措施之后，程序可继续运行。这种情形很少发生 （非常遗憾，因为这是最容易实现的）。

异常处理机制直接建立在这样的分析上。在Eiffel中，一个功能例程程（routine）可以有 “rescue”子句和“retry”指令。这类似于人类合同中的相应条款，即允许异常的、没 计划到的情况发生。如果程序中有“rescue”子句，那么在运行中发生的异常将中断正常 运行（do子句），而启动运行rescue子句。Rescue子句可以有一或多条指令； 其中之一是retry，它将使do子句再执行一遍。一个整型局部变量，如 failure总是在进入该功能例程程时被清零（当然不会在retry后再清零）。