但是在法官的心里，简直有一万匹草泥马奔腾而过啊！

争辩到最后，一脸懵逼的法官表示：你们说得好像都挺有道理的......但是意见相反，所以也不能判定成容易发现.......富士通就不用赔了！

最终，东京地方法院判定：程序bug并不能算是重大过失，由这部分导致的损失无需赔偿。但是，在瑞穗证券电话联络东证交易所后，东证未能履行中止异常交易的职责，属于重大过错方。另一方面，事情的起因是由于瑞穗证券的乌龙指，所以瑞穗证券也不能完全免责。从电话联络那个时间点以后产生的损失，由东证承担70%，107亿日元。

瑞穗证券和东证都对这个审判结果表示不满，上诉到东京最高法院。2015年9月3日，东京最高法院驳回上诉，维持原判结果。长达10年的诉讼终于尘埃落定。

（四）深远影响

看到这里，程序猿和攻城狮应该是松了一口气吧，终于不用为自己写的bug而买单了。

但是且慢！根据这个判例，“bug是否很容易被检测出来”这一点，将会成为今后类似诉讼的判断基准。一旦被判定成重大过失，程序猿们可真是欲哭无泪了。

现在问题来了：身为程序猿，谁也不能保证自己的代码里没有bug。该如何做，才能避免陷入到这种境地中呢？

雷子觉得，既然无法从理论上证明程序里所有的bug都被检测出来，那么，一些行业内公认的指标，例如测试时的case密度，bug密度等，很可能会成为测试是否充分的判断依据。（对，就算没有bug我们也要制造出来！）

此外，bug对应得是否充分，也会成为判断的重要基准。一个bug被发现后，有没有进行深刻的挖掘也是很重要的，即所谓的“横展開”。看到这个词，估计很多同行会做噩梦吧！这个话题很大，雷子今后另起文章和各位同行探讨。

还有一点不要忘记，无论是测试结果也好，还是bug的对应结果也好，

要留证据！

要留证据！

要留证据！

重要的事情说三遍。

本案也让东证认识到，旧交易系统的老朽化以及bug过多等缺陷。随着近年来程序化交易的盛行，旧系统已经越来越无法满足现代证券交易的需要。比起伦敦和纽约等地的证券交易所来，当时东证系统的响应时间要慢100倍啊。

以瑞穗证券乌龙指事件为契机，导出了2010年金融行业的重大项目——东证次世代的交易系统“arrowhead”的构建。这个新系统，依然由富士通负责开发。

法庭上撕得面（ji）红（chi）耳（bai）赤（lian），回过头来该干啥干啥——东证和富士通，还真是一对好基友啊！

本文一部分图片来自网络