您如何看待"不要抓住意外的异常"最佳做法？

我已经读了很多次,不应该盲目地捕捉异常.有人说可以将你的Main()包装成一个catch块来显示错误而不是只退出(例如参见这篇SO帖子),但似乎有一种共识,即如果出现意外情况,你绝不应让程序运行,因为它处于未知状态,并可能以意想不到的方式行事.

虽然我同意隐藏错误而不是修复错误这一事实绝对是错误的想法,但请考虑以下情况:

你有一个庞大的服务器.百万行代码.

启动时,它会将所有Customer加载到其本地缓存中.

对我来说,写这个很有意义:

           foreach (string CustomerID in Customers)
                try
                {
                    LoadCustomer(CustomerID);
                }
                catch (Exception ex) // blind catch of all exceptions
                {
                    // log the exception, and investigate later.

                }

没有盲目捕获,无法加载单个客户只会使所有服务器崩溃.

我绝对宁愿让我的服务器对一个客户产生一些未知的副作用,而不是整个服务器.

当然,如果我运行我的catch代码,我要做的第一件事就是修复代码中的错误.

有什么东西我在这里俯瞰吗？是否有已知的最佳实践(除了'永远不会捕获意外异常'策略'？)

是否更好地捕获LoadCustomer()方法中的异常,从那里重新抛出'CustomerLoadException',并捕获CustomerLoadException而不是调用代码中的所有Exception？

这是一个鲁棒性的问题,即使在无法解释的错误和正确性的情况下仍然继续运作,更愿意完全失败而不是产生不可靠的结果.

显然,如果您正在使用生命支持系统,则不希望系统因未知错误情况而简单地关闭.即使你的状态没有明确定义,也要进行操作可能比终止更好.

另一方面,如果您的程序是购物车,那么完全失败可能更好,而不是潜在地发送错误的项目,或者向错误的个人收取错误的金额.

介于两者之间的所有东西都是灰色区域,这是一个判断调用.总的来说,生命支持系统编程似乎比购物车编程更为罕见,因此广泛的建议是让人们做最常见的事情,即在发生意外错误时失败.据了解,如果您正在处理一个不合适的案例(例如您的服务器示例),您会更清楚.