Question

如果我在ASP.net上运行了一个应用程序并且我在web.config中启用了调试和堆栈跟踪，那么我会得到一个非常好的错误屏幕，告诉我确切的代码导致错误。

可悲的是，在一个调试设置为false的实时系统中，黄色的死机屏幕非常无用，即使启用了堆栈跟踪，也没有显示错误发生的行（这似乎很明显，因为应该没有调试信息）。

我只是想知道是否有办法获得有关错误的良好信息，而无需在web.config文件中启用debug = true。它不一定是黄色屏幕上的改进，我也可以包装我怀疑在try..catch块中冒犯的代码，但是然后在catch块内，是否有办法获得实际代码导致错误？

正如您可能怀疑的那样，这种情况仅在生产中发生错误且没有远程调试器可用：（

编辑：这与“正常”异常有关，例如System.ArgumentOutOfRangeException。如果有更好的方法来获取有关Exception实际发生的更多信息，我希望避免使用日志记录乱码。

Answer 1

面对这个问题时我要做的第一件事就是向global.asax添加一个全局异常处理程序，例如：

    protected void Application_Error(object sender, EventArgs e)
    {
        Exception ex = Server.GetLastError();
        Log.WriteException(ex);   // this is your code
    }

您也可以在页面级别执行此类操作，但我认为您最好在应用程序级别执行此操作。当您将异常写入日志时，您还可以写出更多信息以帮助您重新创建错误，例如请求参数或会话信息。

另一个好的做法是在web.config中添加这样的部分：

  <customErrors mode="On" defaultRedirect="error.html">
    <error statusCode="500" redirect="500.aspx"/>
    <error statusCode="404" redirect="404.aspx"/>
    <error statusCode="403" redirect="403.aspx"/>
  </customErrors>

这将显示所有未知错误的error.html，并显示您为某些特定错误定义的相应页面，您可以向用户提供有关如何解决错误或帮助他们找到错误信息的更多信息。寻找。

asp.net中的错误处理是一个非常重要的主题，但这应该是一个很好的起点。

Answer 2

您是否可以改编某种应用程序错误日志记录，例如Log4Net或ASP.NET Health Monitoring？

Answer 3

不使用日志记录乱丢代码，我认为解决这个问题的方法是将代码重构为更小的方法。听起来你有一个很大的方法可以做很多事情，并且异常可能发生在该方法的许多地方。这种情况在我之前发生过，而我缩小范围的方法是将方法分解为更小的块。由于您仍然可以在堆栈跟踪中看到方法名称，因此制作更精细的方法将帮助您跟踪抛出异常的位置。

发布配置中的“好”ASP.net堆栈跟踪或如何获取有问题的代码

3 个答案: