Question

我正在使用ASP.Net 2.0。我发现自己陷入了尴尬的境地，因为我无法找到错误的原因。到目前为止，在访问数据时我一直在使用这个习惯用法。

try
{
  access data
}
catch (SqlException exception)
{
  Response.redirect("error.aspx");
}
finally
{
  Dispose of connections, commands etc
}

现在我永远无法看到实际错误是什么，因为它始终处理。有时我可以运行SQL事件探查器并捕获最后一个语句并在SQL查询分析器中运行它并查看是否存在问题。那显然很可怕。

所以我认为global.asax Application_Error方法会保存我，我会给自己发电子邮件异常。但是这种方法似乎只被称为未处理的异常。所以我的问题是，最好不要处理异常，系统发送电子邮件并使用customError页面。或者将异常压缩到会话中更好，重定向到error.aspx然后尝试对错误做一些事情。有没有办法再次调用Application_Error？因为如果我再次在error.aspx处抛出异常，那么我会得到死亡的黄色屏幕？

Answer 1

在我看来，使用库（例如log4net）来记录异常并再次抛出异常，让asp.net将错误页面重定向到web.config customErrors section的自定义页面。 / p>

Log4Net或Enterprise Library的Exception Handling Application Block都有电子邮件发送功能。

另请参阅ELMAH，非常智能且可插入的异常处理模块。

Answer 2

这里的记录非常宝贵。在catch块中，将错误记录到日志文件中。养成这样做的习惯是一个好主意，可以真正节省生命，看看最新情况。看看nlog是一个日志库。还有各种工具允许您分析由nlog生成的日志

Answer 3

您可以在重定向到错误页面之前在某处简单地记录异常。

类似的东西：

try
{
  //access data
}
catch (SqlException exception)
{
  LogException(exception); 
  Response.redirect("error.aspx");
}
finally
{
  //Dispose of connections, commands etc
}

因此，您可以双向使用，客户将被定向到错误页面，并且您的异常仍会记录在某处，供您查看并深入了解。

顺便说一句，有许多免费的日志记录库，你可以使用，特别是 log4net和企业库

Answer 4

由于您使用的是ASP.NET 2.0，因此最好不要做任何事情。

ASP.NET添加了一个名为ASP.NET Health Monitoring的功能。默认情况下，这会将详细的异常信息记录到应用程序事件日志中。它可以配置为将不同类型的问题发送到不同的目的地。

所以，什么也不做，一切都会好的。

是最好处理SQL异常，还是在Global.asax中使用customError页面和Application_Error方法？

4 个答案: