ASP.NET全局错误处理和异常日志记录以及IIS配置自定义错误页面

时间：2021-07-31 17:42:02

应用场景和使用目的

很多时候，我们在访问页面的时候，由于程序异常、系统崩溃会导致出现黄页。在通常的情况下，黄页对于我们来说，帮助是极大的，因为它可以帮助我们知道问题根源，甚至是哪一行代码出现了错误。但这对于用户是非常可怕的，因为用户不知道发生了什么，也无法了解黄页给出的内容。甚至，如果我们遇到一些不友好的人，他们会拿这些内容大做文章，对我们网站产生威胁。

那我们如何在程序异常、系统崩溃时，不会出现黄页，并且还可以给出一些更加友好的提示呢？甚至在我们需要的时候，可以收集这些异常信息，并加以分析，能够迅速定位错误来源，解决问题呢？以下给出了三种解决办法。

使用customErrors，用户自定义错误

在Web.config的<system.web>节点下添加

 <customErrors mode="RemoteOnly" defaultRedirect="/error/error.htm">

 　　<error statusCode="404" redirect="/error/404.html" />

 　　<error statusCode="403" redirect="/error/403.html" />

 　　<error statusCode="500" redirect="/error/500.html" />

 </customErrors>

mode 指定启用、禁用或仅对远程客户端显示自定义错误。mode=RemoteOnly为默认值，指定仅向远程客户端端显示自定义错误，并向本地主机显示 ASP.NET 错误。 当mode=on时，如果没有指定 defaultRedirect，用户将看到一般性错误。当mode=off时，将显示详细的错误。

defaultRedirect 指定发生错误时浏览器指向的默认 URL。如果没有指定 defaultRedirect，则会显示一般性错误。

statusCode 指定导致重定向至错误页的 HTTP 状态码。

Redirect 向客户端提供错误信息的错误页。

使用httpErrors，覆盖customErrors

强烈建议，为什么？在默认情况下，customErrors跳转自定义错误页时会进行302重定向。当我们请求到一个错误页事，页面会先进行302重定向，然后返回200OK。对于用户来说，这个是完全没有问题的，因为做到了友好的用户体验。但对于爬虫，它会认为这是一个错误页面，比如404，并且会将其录入。而且，customErrors每次重定向后都会带上一个小尾巴aspxerrorpath，比如http://yoursite.com/error/404.html?aspxerrorpath=/exceptionpageurl。还有一些时候，由于customErrors属于托管环境下的自定义配置，当请求尚未到达ASP.NET管线时，customErrors是不能发挥其作用的，所以使用httpErrors也包括同时也可以处理请求在未到达ASP.NET管线同样也能捕捉到异常。

在Web.config的<configuration>/<system.webServer>节点下添加

 <httpErrors errorMode="Custom" existingResponse="Replace" defaultResponseMode="ExecuteURL">

  　　<remove statusCode="403" subStatusCode="-1"/>

  　　<remove statusCode="404" subStatusCode="-1"/>

  　　<remove statusCode="500" subStatusCode="-1"/>

  　　<error statusCode="403" path="/403.html" prefixLanguageFilePath="" responseMode="ExecuteURL"/>

  　　<error statusCode="404" path="/404.html" prefixLanguageFilePath="" responseMode="ExecuteURL"/>

  　　<error statusCode="500" path="/500.html" prefixLanguageFilePath="" responseMode="ExecuteURL"/>

  </httpErrors>

详情参见http://www.iis.net/configreference/system.webserver/httperrors

在Global.asax中的Application_Error方法中统一处理错误页，并记录日志

前两种方式都是可以做到自定义错误页面，但唯独不能自定义记录日志，而这种方式则可以同时满足这两种需求。

   protected void Application_Error(Object sender, EventArgs e)

   {

       Exception lastError = Server.GetLastError();

       if (lastError != null)

       {

           if (lastError is HttpException)

           {

                   Server.ClearError(); // 清除错误状态

                   Server.Transfer($"/error/{Response.StatusCode}.html"); // 跳转指定友好体验的页面

                   // 可同时使用两种方式记录日志

                   // 第一种 使用log4net

                   // 第二种 使用数据库

          }

      }

  }

log4net记录异常日志，园子里已经有很多文章详细讲解了，在这里就不赘述了。数据库记录异常日志，要说明一下表设计，因为要考虑到可能不是只有这一个地方要记录异常日志，还有比如在Application_BeginRequest，Application_EndRequest等等。所以表设计的字段应该含有当前所在上下文，所报异常源，异常信息等字段。这样会在我们日后快速定位错误，排查异常起到很重要的作用。

这里还要注意一下是Server.Transfer不会更改URL，如果需要更改URL可使用Response.Redirect进行跳转。

总结

customErrors由于对SEO造成不利，所以现在已经不建议使用了。

httpErrros不会造成302重定向，同时能捕获到未到达ASP.NET管线的异常请求，但不能自定义异常日志。

Application_Error同时可以自定义错误页面，也可自定义日志。但需要注意的一点，Application_Error由于也位于托管环境，所以同时也无法捕捉到未到达ASP.NET管线的异常请求。

因此，根据三种解决办法，首推httpErrors和Application_Error。

相关文章