了解 ASP .NET (WebForms) 中的错误处理
本文关键字:错误 处理 WebForms ASP NET 了解 | 更新日期: 2023-09-27 18:35:10
我有一个 Web 窗体 (.NET 4.0) Web 应用程序构建为:
正在尝试遵循一些有关错误处理的教程,但到目前为止,我得到的结果不一致。
我的问题是我应该如何处理应用程序中的错误?
我应该将所有方法包装在 try/catch 中吗?
我应该只用 try/catch 包装业务层中的方法吗?
如何使用 WCF Ajax 方法处理 PortalLayer 中发生的错误?
例如,我将以下内容添加到我的 Global.asax 文件中:
void Application_Error(object sender, EventArgs e)
{
// Code that runs when an unhandled error occurs
Exception exc = Server.GetLastError();
if (exc is HttpUnhandledException)
{
if (exc.InnerException != null)
{
exc = new Exception(exc.InnerException.Message);
Server.Transfer(@"'Pages'Error.aspx?handler=Application_Error%20-%20Global.asax", true);
}
}
}
然而,大多数时候这不会被调用。我只是看到屏幕上显示错误消息的错误(就像美化的警报)。
或者,如果调用此方法,则 exc 不是 HttpUnhandledException,因此传输永远不会发生。
我也在我的 web.config 中尝试过这个,但我没有看到这有什么作用。(如果我把它注释掉,我会得到相同的结果)
<customErrors mode="On" defaultRedirect="Error.aspx?handler=customErrors%20section%20-%20Web.config">
<error statusCode="404" redirect="ErrorPage.aspx?msg=404&handler=customErrors%20section%20-%20Web.config"/>
</customErrors>
最终目标是将用户重定向到页面(或者可能只是很好地显示错误),同时将其记录在文件中或将错误写出数据库。
服务器处理页面(请求.aspx,.ashx 资源)时,主线程中发生的异常将调用void Application_Error(object sender, EventArgs e)
。
在两种情况下不会调用它:
- 您在处理资源时触发.aspx新线程,异常将发生在该新线程中
- 在 Web 服务方法、WCF 方法等(即非.aspx资源)中
- 异常是"坏屁股"异常 - 损坏应用程序域的那种 -
StackOverflowException
或OutOfMemoryException
因此,对于 WCF,Web 服务将所有入口点包装在
try {}
catch(Exception e) {
Logger.Log(e);
throw;
}
声明(请注意,如果您有很多这样的,请将时间投入到更通用的解决方案中)。
另请注意 - 如果您的错误页面上有错误,您将获得黄屏死机(显然)。所以我更喜欢将静态 html 页面显示为错误页面(出现问题的可能性最低)。
在您的错误处理代码中,您没有清理错误状态,我也希望Redirect
Server.Transfer
错误处理。最终截图如下所示:
var ex = Server.GetLastError();
Logger.Log(ex);
Server.ClearError();
Response.Redirect("/error.aspx");
最后一点 - 不需要自己做错误日志记录(好的程序员是懒惰的 - 就"不要重新发明轮子")而言 - 有很多很棒的日志记录模块,如Elmah,Microsoft企业库或log4net。