如果到了让用户手动干预的环节，应用仍未达到用户的预期，那我们就无能为力了。正如这部分标题所暗示的，并不是所有错误都可以被恢复。后端API并不总是能正确做出响应。组件在生产环境中是会存在bug，有些bug甚至在很多年后才会被发现。

这种重大错误就像在人群中摔了个脸朝地。不断重试返回的是相同的结果，重启组件也不会有影响。此时向用户寻求输入是没意义的，或许用户不可能再重现失败的情形，或许我们根本就没有提供输入方式。

不管是哪种情况，解决的办法都是切换到快速失效模式——在异常情况下禁用组件或整个应用。如果只是禁用组件，就必须确保应用可以脱离该组件正常工作。这又回到了飞机使用一个引擎降落的例子——它是否能工作？如果不能，我们必须关闭整个应用。

这种解决方法可能乍一看有点激进。但是，这么做可以帮助支持小组排除一大部分麻烦。出错组件导致系统在运行中出现新错误的几率也会更小。可扩展的错误处理方式能提高胜算，只要不在恢复错误时自作聪明，成功的机会就更大。

既然我们已经拥有了强健的错误检测和恢复机制，那么是时候将注意力放到性能和复杂度的影响上了。在大型JavaScript应用中，任何行为都是有代价的——任何收获，都会给可扩展性带来新的挑战。错误处理也同样如此。

错误处理直接影响了性能和复杂度。软件出错的原因很奇特，当找不到优雅的处理方法时，我们需要复杂的实现修复它们。复杂的代码通常不利于性能。因此，让我们来看看，是什么拖慢了异常处理代码的性能。