您认为“不要捕获意外的异常”最佳实践是什么?

这是一个问题 鲁棒性 ,即使出现无法解释的错误,也会继续运行,vs 正确性 更倾向于完全失败,而不是产生不可靠的结果。

很明显,如果您正在工作,例如生命支持系统,您不希望系统由于未知的错误条件而简单地关闭。即使您的状态没有很好地定义,但对操作进行cotning可能比终止要好。

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

中间的一切都是灰色地带,这是一个判断的信号。总的来说,似乎生命支持系统编程比购物车编程更为罕见,因此广泛的建议是让人们做最常见的事情,这在发生意外错误时会失败。可以理解,如果您正在处理一个不合适的案例(如服务器示例),那么您将了解得更好。

“有什么我可以忽略的吗?”

对。

“是否有已知的最佳实践(除了‘从不捕捉意外异常’策略’?)”

对。封装。责任分配。这个 S. O. L. I. D. 原则。

在loadcustomer()方法中捕获异常,从中重新引发“customerloadException”,并捕获customerloadException而不是调用代码中的所有异常,这样更好吗?

对。它封装了类定义中可能出错的所有内容,这些类定义提供了 loadCustomer 方法。

我认为这取决于Senario,但作为一个规则,我只能通过每天使用该应用程序来捕获异常,并使用某种未散列的异常报告/日志记录工具,如用于ASP.NET的运行状况监视。但是,如果它是应用程序的一个关键部分,不能有未散列的异常,我会捕获所有异常,然后再次报告/记录它们。

这是一个个案。如果您可以保证加载失败不会对其他客户产生任何影响,那么日志记录和跳过该特定客户似乎是合理的。不过,并非所有的例外情况都是这样。尤其是在错误情况下,例如: VirtualMachineError ,通常情况下,问题会影响整个程序的运行,而您 应该 中止。

我绝对喜欢让我的服务器在一个客户身上有一点未知的副作用,而不是让我的整个服务器停机。

您如何知道在loadcustomer()中引起异常的bug没有承载任何其他内容?总的来说,我想我更喜欢“日志异常,将异常重新抛出到更高的级别”,然后很可能退出。

在这个特定的案例中,我可能会为处理它的两种方式争论,但是一般来说,处理你没有明确处理方法的错误是不理想的。

我认为您缺少的是桌面应用程序的“最佳实践”不一定与服务器的“最佳实践”相同,服务器的“最佳实践”与网页的“最佳实践”不同。

如果一个网页抛出了一个未处理的异常,您会认为是“meh”,然后点击刷新。如果一个桌面应用程序抛出一个,你可能会丢失一些数据,并非常恼火。如果一个服务器抛出一个,那么整个业务可能会停止,直到它被修复。

它还取决于修补的容易程度——如果你很容易将修补程序推送到所有的安装程序(比如你自己的服务器或内部应用程序),那么最好不要让异常被发现。如果你正在写一些无法修补的东西(一个旧控制台或嵌入式设备应用程序的游戏),那么你最好接受这个例外。

当然,在任何情况下,最好让您的测试捕捉到问题,这样您就可以正确地处理它,但我们都知道错误会发生…

抓住你所知道的例外情况是非常好的。您可能期望在示例中出现NullObjectException。抓住那是完全合理的。

当您捕获一般异常时,您实际上是在说“我不知道发生了什么错误,或者服务器是否着火,以及 我不在乎 “虽然您的服务器可能会继续运行,但不知道内部状态是什么,也不知道这个异常是否会导致道路上的交通事故。

此外,通过捕获此时的任意异常,如果稍后发生崩溃,您就离“实际”错误发生的位置更远了——这将使查找错误变得更加困难。

同样,虽然没有捕捉到一般的异常可能会导致立即崩溃,但在开发周期的早期,这种崩溃更可能被捕捉到,并且很容易被修复(因为您将知道错误实际上发生在哪里)。

抓住例外真的没有好处。

我在这方面经验不足。然而,在我看来: 1。几乎任何规则都有例外。知道何时打破规则很重要。 2。在异常处理的情况下,盲目地捕获异常几乎不是一个好主意。这是因为您可能会捕获一些真正意外的错误。

例如,在python(至少2.5.2)中,盲目捕获将允许我捕获ctrl+c信号(linux)。这意味着我不能在紧急情况下终止申请。

3. 对于Web服务器代码,您可能需要执行以下操作之一
   +使用一个自定义异常,如果客户未能加载并记录/更正该异常,则抛出该异常。
   +在代码的更深层次中使用异常处理,并在那里进行处理。

好吧,让我这样说……比如说神秘的客户因为不存在而无法加载,比如说有人已经知道如何破解系统的前层。现在假设黑客做了各种各样的恶意的事情,直到他碰巧触发了一些函数,试图从一个未知的客户价值中读取数据,现在系统无论如何都会崩溃,但黑客可以对无效的客户进行各种破坏。

那真的更好吗?

为了解决真正危及程序稳定性的异常情况,最好编写这种代码:

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

            }

当您知道哪些对象和资源可能受到影响并丢弃所有这些对象时,可以很好地捕获所有异常(但不是错误)。

所以在你的情况下 可以 可以处理将整个过程转换为NOOP的异常。但你必须确保: -没有其他共享资源受到影响(例如,一个休眠会话在异常后可能会死机) -一个完整的(trans)操作被取消,而不仅仅是一半。这意味着这种异常处理只能出现在特殊的地方,通常直接“在”用户界面下。示例:用户按下一个按钮,该按钮应该加载一个客户,更改其地址并再次保存。当其中任何一个出错时,您可能会捕获异常,阻止所有剩余步骤的发生,丢弃客户对象,并显示一条消息:对不起,不起作用。

但是,如果您捕获异常(例如,在修改地址时),然后继续工作,那么用户拥有的客户对象在其控制下会更改地址,而实际上,他控制的客户对象的地址已被破坏。情况不太好。

所以规则是:定义控制事务的层。这应该是捕获异常的层。可能是swingAction,也可能是线程,可能是public void main,也可能像您的示例一样在循环中。

我以前是通过捕获一个一般的“异常”而不是单个类型而被捕获的。这意味着你泄露了一些关于到底出了什么问题的信息。您通常希望以不同的方式处理每种类型的异常。

另外,顶级异常处理只能用于记录错误并重新启动应用程序。如果您不知道什么类型的异常导致了您的程序可能处于无效状态的错误,那么您可能是内存不足或其他原因。

这取决于你站在哪里。如果你处于较低的水平,你可以预见到大多数的例外,你应该明确地只捕获那些例外,剩下的都会冒泡。当您到达GUI或顶级逻辑时,所有已知的异常都会被捕获,最终只会 想不到的 例外情况。现在您有两个选项:

1. 悲观主义:表现出例外,放弃。
2. 乐观的观点:你有信心你已经抓住了所有批评家的例外,所以你把例外吞下去继续。( ON ERROR RESUME NEXT 有人吗?)

无论哪种方法,您都要记录异常并确保定期检查日志。

最后,这是一个“一切取决”的情况。更糟糕的是什么?继续使用错误数据还是意外退出?它是一个关键系统吗?它是由另一个系统使用的输出吗?等

不管怎样,所有重要的例外 应该 已经被应用程序的更深层次所捕获。

如果由于日志,您发现了未处理的异常,请更正代码、测试并重新部署。

许多语言中异常层次结构的一个主要问题是,异常是按类型或调用类而不是按严重性组织的。通常,当抛出异常时,是因为某个方法在执行任何操作之前确定了其前提条件未得到满足。抛出异常的第一个例程的调用者可能在该点上做过或没有做过任何重要的事情。在许多情况下,调用方在调用例程之前所做的任何操作都只对临时变量起作用,当异常冒泡时,临时变量将消失。因此,在绝大多数情况下,当像loadDocument()例程这样的程序抛出异常时,尝试加载文档将不会对任何仍然存在的状态产生任何影响。如果加载文档的失败尝试没有副作用,并且应用程序准备好处理文档未加载的事实,那么应用程序就没有理由不继续。困难在于知道是否有副作用。

现有异常处理系统中缺少的一个特性是异常中的虚拟IsResolved属性。在处理“catch”块后,系统将检查isResolved是否返回false。如果非空且返回true,则将调用UnsolvedExceptionException,并将前一个异常作为其InnerException(UnsolvedExceptionException.IsResolved将调用其InnerException的IsResolved方法)。

大多数IsResolved实现将测试返回布尔值的函数的委托列表是否为空;如果不是,则如果所列委托中的任何一个返回为真,则返回为真。如果异常意味着未释放的对象已损坏,IsResolved方法可以返回该对象的已释放标志。如果对象已被释放,则其损坏将不再相关。如果对象被包装在一个using块中,这种行为将导致异常渗透到对象被释放的点,但不会进一步。

像outofmemoryException这样令人讨厌的异常只能通过显式调用outofmemoryException.AcknowledgeoutofmemoryCondition之类的东西使其IsResolved方法变得高兴。许多其他引发异常的例程都会立即使IsResolved方法返回true(例如Dictionary.GetValue引发,因为找不到键,那么就字典而言,一旦引发异常,就会立即解决异常)。

不幸的是,我不确定这样一个方案能在多大程度上被添加到.NET这样的现有平台上。不过,如果将来有人开发类似的系统,那么它似乎是一个有用的特性。