契约、并行和异常

一直认为，契约是类型系统不可或缺的一部分，虽然现在的主流语言都缺乏它。我们知道，现在的组件都是隐藏其实现，公开其接口的。这为大型的复杂系统提供了必要的抽象机制，可是，现在的接口都是只描述了组件可以接受的消息类型（或者习惯上称作方法的签名），对于该组件在什么状态下可以接受该消息，该消息有什么要求和限制，以及组件对于该消息的响应是如何的都没有描述。这些是应该描述的。在支持契约的Eiffel语言中，它们被分别描述为 Precondition和Postcondition。契约不仅仅是一个类型安全的必要组成部分，它还是一个设计工具，可以借此理清各个组件的权利和义务等等关系。

近来突然感觉，契约这个东西可以相当完美的套在并行模型上。让我们再捋一遍。precondition，也就是说某个组件要接受某个消息必须满足的一些条件，在并行环境下，它正好可以表述为同步点，环境（或者说别的组件的状态的总和）所必须具有的状态。待到这个状态点达到了，我们拥有这个 precondition的组件就可以继续运作了。postcondition表明组件对环境的影响，也就是说，当它执行某个方法，会对环境造成的“影响”。

有了这个，我们似乎可以在此基础上证明我们的并行模型是否有问题，会不会产生死锁现象，最不济也可以让我们不需要手动同步各个组件，只要它们规定好自己的 precondition，在条件满足的时候，运行时自动选择该组件开始运行。我觉得这比现在我们采用的低级的同步原语简单的多，功能也没有丝毫降低。

异常是一个一直没有什么定论的东西。由于异常是运行时的，所以它似乎不应该从静态类型系统上借力，照此说来，Java的Checked Exception似乎不太正常，可是有时候我们也会觉得我们似乎可以估计出可能的异常，对于不能预测的异常，大家都没有什么意见，让他们throw，然后导致GameOver就行了，问题集中在我们似乎可以预测的异常上面。

我们先深入的想想，我们要异常来干什么？对付各种异常情况。可是异常情况是什么情况？为了搞清楚这个，我们先得搞清楚什么是正常情况。我们的前提是静态类型正确的程序。也就是我们上面描述的那种有契约和接口的那种程序。正常情况似乎就是，不光是静态类型正确，动态类型也是正确的，并且程序的逻辑也是正确的。上面我们可以知道，如果支持契约，那么我们可以堵住一大批程序的逻辑错误。现在我们可以这样描述异常了，所有不能保证动态类型安全和不能保证逻辑正确的情形。那么，如果程序出现逻辑错误，那就是说我们的契约规定不到的地方，也就是说，是出现了我们分析和设计阶段没有预料到的情况，那么这时候我们能怎么办？没有办法，程序是死的，它一旦被规定出来，就定型了，不能再修改了（这儿暂时不考虑lisp之类的语言），我们唯一能做的就是GameOver。至于 exception，这儿可能就一个作用，体面地退场。当然，如果我们的程序是自适应的，我们可以动态的修改我们的结构，让程序继续运行下去。这就是异常的另外的作用了，现在似乎还看不到exception被这样使用。