架构 – 您如何看待“不要抓住意外的例外”最佳做法?

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

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

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

启动时,它会将所有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?

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

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

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

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

相关文章
相关标签/搜索