<分区>
最近，我发现自己和老板就我们的网络应用程序(一个 c# asp.net MVC 应用程序)中的异常处理发生了很多争论。
基本上对话是这样的:
老板:“我们的程序出了点问题，客户x的数据库今天宕机了，大家都看到了错误页面。”
我:“大多数情况下，应用程序中的每个页面都使用数据库来做某事(错误页面除外)，除了显示错误页面之外没有其他合理的选择。”
老板:“我们的应用程序应该更具弹性——不需要数据库访问的应用程序部分应该仍然可以运行。”
通常，情况会像这样极端，但有时我们会遇到这样一种情况，我们正在与另一个服务集成，我们仍然可以安全地显示页面的其他部分或完成操作，尽管有一些烦人的代码代码的后面部分需要稍后使用可能失败的操作的结果。如果有很多可能的故障点，这可能会变成一些极其难以管理的代码。
一般来说，对于一个“普通”的网络应用程序(非关键任务等)，“优秀”的开发人员会花费多少时间来使他们的代码具有足够的弹性来处理这些情况。我的老板似乎认为代码应该能够处理几乎所有情况(你不能只捕获异常吗？)。当存在许多可能的故障点时，我看不出这有何经济意义。