问global.asax中的Application_Error真的是处理错误的方法吗？

EN

我发现的简短答案是，如果你想保留这份工作，即使你不同意，你也要按照指示编写代码的方式进行编码。

但是，如果您只捕获Global.asax中的错误，那么您就失去了本地变量调试和优雅的错误处理。在Global.asax中处理的错误通常不会正常失败。

我通常会在Global.asax中发现任何未处理的错误，但对我来说，只在这里处理这件事就像没有刹车一样，因为它有安全气囊。(是的，我喜欢比喻)

所有这一切的关键是区分预期和意外的异常。在编写代码时，应显式捕获预期可能发生的异常。

最好的例子就是除法。分子除以分母。您知道除以零会引发异常。此时，您可以捕获要处理的预期异常，也可以在遇到异常之前显式抛出异常(基本上是由您的需求指定的)。如果你什么都不做，意外的异常就会起作用。

根据大多数软件的编写方式，未处理的异常对于用户体验来说是糟糕的，不幸的是，更常见的异常类型。它们是由频繁的代码改动，缺乏对需求的理解，对更广泛的系统的有限知识，以及纯粹的懒惰而引入的。通常，当遇到它们时，它们会导致软件的操作方面发生突然变化。

全局异常处理程序的目的是在收集尽可能多的有价值的信息时/gracefully恢复或通知用户出了问题。/我个人认为应该以一种有意义的方式记录这些异常，并尽快解决这些问题。如果遇到这些问题，很可能是预期的条件没有被强制执行或处理，或者代码中存在导致应用程序进入无效状态的逻辑问题。

如果使用得当，全局异常处理程序是一个很好的安全网，总体上可以用来帮助提高代码质量。所涉及的风险通常来自于只依赖于全局异常处理程序，或者忽略了对报告的内容采取行动。

您应该只在可以对错误采取措施时才捕获错误(而不仅仅是记录错误)，这是非常罕见的。

例如，捕获SqlExceptions以重试死锁是合理的：

catch(SqlException exception) {
    if (exception.Number == 1205)
        // call retry code 
    else
        throw;
}

如果你只是想记录这些异常并显示一个通用的‘and’消息，那么在你的页面的处理器方法中捕捉每个异常是不合理的。。把这些代码放在一个地方：Application_Error。

要处理您可以预料到的问题(如被零除错误)，您应该首先防止无效输入，或者在产生异常之前处理条件：

// Make sure the exception never happens and provide meaningful feedback
if (divisor == 0) {
    txtErrorMessage.Text = "Enter a value greater than zero.";
    return;
}

txtQuotient.Text = dividend / divisor;