10.3.2  缺陷排除与缺陷存活

尽管您可以选择更赞成缺陷存活而不是缺陷排除，但问题是异常处理代码可能会非常复杂，以至于又在软件中引入缺陷。这样，异常处理成了失效的源头，而不是提供一种机制来帮助实现容错。优先选择缺陷存活而不是缺陷排除降低了软件正常运转的可能性。全面而彻底的检测会去除缺陷，从而减轻对异常处理的压力。值得一提的是异常处理不会以独立的代码段的形式存在。它们存在于整体软件架构的环境中。软件中的容错之旅常常是从达到以下认识开始的：

再多的异常处理也无法拯救有缺陷或不适当的软件架构

软件容错同软件架构的质量直接相关

异常处理架构不能取代各个测试阶段

为使得关于异常处理的讨论清晰明确，理解异常处理架构作为整体存在于软件架构的环境中很重要。这就是说，异常是由PBS和PADL分析来确定的。解决方案模型包含PBS。如果应用程序架构的PBS有无法避免、不可控制、无法解释的背离，则存在异常。因此，异常是通过明显地铰接在一起的架构来定义的。如果软件架构不适当、不完整、考虑不足，那么任何进行事后异常处理的企图都是高度可疑的。另外，如果在测试阶段走了捷径(如不完全的压力检测、不完全的集成测试、不完全的白盒测试等)，那么必须永远地加入异常处理代码并使它的复杂度持续增加，最终降低了软件的容错性能减少了应用程序的声明式架构的优势。另一方面，如果软件架构是合理的，并且异常处理架构与PBS和PADL的第3层、第4层和第5层兼容且一致，那么并行程序就可以实现高度容错了。如果您在达成上下文失效复原(context failure resilience)的目标时，理解软件应用程序架构和测试所发挥的作用，那么显然您会优先选择缺陷排除，而不是缺陷存活。缺陷排除在测试中发生。