【发布时间】:2015-04-30 09:07:34
【问题描述】:
对于我正在处理的项目,我们正在实施的其中一件事是我们在我的一些团队中为一些较旧的 ASP.NET 和 MVC 项目提供了代码 - 一个 Application_Error 异常捕获器,可将电子邮件发送到具有异常经验和最相关细节的开发团队。
它的外观如下:
Global.asax:
protected void Application_Error(object sender, EventArgs e)
{
Exception ex = Server.GetLastError();
string path = "N/A";
if (sender is HttpApplication)
path = ((HttpApplication) sender).Request.Url.PathAndQuery;
string args = string.Format("<b>Path:</b> {0}", path);
// Custom code that generates an HTML-formatted exception dump
string message = Email.GenerateExceptionMessage(ex, args);
// Custom code that sends an email to the dev team.
Email.SendUnexpectedErrorMessage("Some App", message);
}
不过,有一个“小”问题 - 当我故意让一部分代码抛出异常以测试此机制时...
public static void GetMuffinsByTopping(string topping)
{
throw new Exception("Test Exception!", new Exception("Test Inner Exception!!!"));
// Actual repository code is unreachable while this test code is there
}
前端 JavaScript 正在立即拦截 HTTP 500 请求,但没有到达上面提到的 global.asax.cs 代码(我在方法的第一行设置了断点。)
问题:我可以通过什么方式让“旧”Application_Error 处理程序发送错误电子邮件,以便我们团队的开发人员可以更轻松地调试我们的应用程序?
【问题讨论】:
-
您可以将错误处理逻辑抽象为
Application_Error调用的单独方法,将Web API 方法主体包装在try/catch 中,然后手动将错误逻辑从Web API 传递给抽象方法错误。我敢肯定,这不是最干净的方式,但它应该很容易实现并且“正常工作”。对于更清洁的方法,您可以查看Exception Handling in ASP.NET Web API。 -
我同意这是一个很好的“让它工作”的建议。我问这个的原因是,根据我的技术主管的指导,在每个 API 方法中都有一个
try/catch实际上是我想要摆脱的。不过,如果所有其他方法都失败了,我们的团队可以将其用作后备。这将是一个非常令人讨厌的模式。 -
我编辑了我的最后一条评论。查看我提供的链接,并查看异常过滤器。这看起来是一种避免在所有 Web API 方法体中使用 try/catch 的好方法。
-
这对我来说很有效。您是否介意回答您的评论,即使用异常过滤器是一种更好的方法?
标签: c# asp.net .net asp.net-web-api error-reporting