8

我最近加入了一个 asp.net mvc 项目，该项目正在进行中，在处理控制器中的异常方面没有太大的一致性；一些开发人员将数据返回给客户端，让用户知道出了什么问题，而其他开发人员则将它们返回给处理和记录它们的服务器级处理程序——而不让用户知道发生了什么。

在我看来，这两种方法本身都是错误的，需要相互补充。我坚持的是如何做到这一点。我假设最终的异常处理程序/记录器可以在捕捉到特别讨厌的东西时将用户重定向到错误网页，但这将机制限制为严重的东西。

我正在寻找一种在捕获异常时同时执行“抛出”和“返回...”的方法，因此我对其进行排序和记录服务器端并获取数据客户端，让我告诉用户出现了问题。

我在 asp.net 方面的专业知识非常有限，虽然我相信我对 mvc 的了解足以让它不会成为问题，但这是一种“最佳实践是什么？” 与不太关心最佳实践的人一起工作的人提出的问题。

4

2 回答 2

2

有一个名为 Elmah 的好项目，用于记录 ASP.NET 应用程序中的错误和异常。你可以在这里找到

ELMAH（错误记录模块和处理程序）是一个完全可插拔的应用程序范围的错误记录工具。它可以动态添加到正在运行的 ASP.NET Web 应用程序，甚至是一台机器上的所有 ASP.NET Web 应用程序，无需重新编译或重新部署。

将 ELMAH 放入正在运行的 Web 应用程序并进行适当配置后，您无需更改任何一行代码即可获得以下功能：

  • 记录几乎所有未处理的异常。
  • 用于远程查看重新编码异常的整个日志的网页。
  • 用于远程查看任何记录的异常的完整详细信息的网页，包括彩色堆栈跟踪。
  • 在许多情况下，即使关闭了 customErrors 模式，您也可以查看 ASP.NET 为给定异常生成的原始黄屏死机。
  • 每个错误发生时的电子邮件通知。
  • 来自日志的最后 15 个错误的 RSS 提要。
于 2012-04-10T12:08:18.237 回答
0

我正在开发的 MVC 应用程序实现了Application_ErrorinGlobal.asax以处理从应用程序抛出的异常，然后将用户重定向到标准错误页面。错误页面的控制器处理日志并显示有关错误的足够信息，以允许支持人员在系统中找到他们的会话并帮助解决任何问题。

于 2012-04-10T12:10:53.897 回答