ASP.NET 常见错误页面最佳实践答案

【问题标题】：ASP.NET Common Error Page Best PractisesASP.NET 常见错误页面最佳实践
【发布时间】：2023-11-15 14:13:01
【问题描述】：

我正在开发一个 ASP.NET Web 应用程序。我正在为整个应用程序实现日志框架。

Web 应用程序大约有 7-8 个页面，是一个简单的 CRUD 操作 Web 应用程序。

它是一个 Azure 托管应用程序。以下是我正在遵循的日志记录和异常处理方法。

1) 在数据访问层中添加了 Try...Catch 块和 Click 事件。

2) 捕获错误后，我将异常传播到 Globabl.asax 级别，并在 Application_Error 事件中将错误记录到事件日志和跟踪日志中。

3) 在 Global.asax 文件中之后，我将重定向到错误页面以显示用户友好消息并链接到失败的页面。

4) 只是想知道这样做是否是一种好方法。

感谢朋友。

【问题讨论】：

标签： asp.net error-handling azure

【解决方案1】：

您是否真的在处理 DAL 上的异常（即记录、尝试修复它等）？如果不是，那么 try catch 除了旋转循环之外没有其他用途。点击事件也是如此，但在 UI 上处理错误并不是一个坏习惯，即使您并没有真正对它们做任何事情，因为您会将用户从丑陋的错误页面转移到您自己的友好消息.

如果您确实无法处理抛出的异常，则单个错误页面可以正常工作。好处是上市时间，因为您编写宝贵的小代码以避免向用户显示丑陋的信息。缺点是用户错过了上下文。除了作为备份（有一个我没有想到的错误超出了我的第一行处理程序）之外，我并没有真正找到适合所有异常处理程序的大小。

如果您基于 HTTP 状态进行处理并且使用 config.

另一种模式是设置您自己的基本页面并将其用作错误处理程序。然后，您可以在发生错误时留出一个容器来填充。这种方法非常适合添加上下文，因为用户仍然可以看到他所在页面的一部分，但是您已经给出了错误消息，所以他知道事情已经失败了。我已经看到这种模式与发生错误时添加到容器中的用户控件一起使用，但这有点复杂，因为您必须设置一个代码表和要显示的正确消息（这可能是错误的和本身）。

【讨论】：

【解决方案2】：

为什么不使用 ASP.NET 自定义错误页面？您可以为每个状态代码指定每个错误页面，也可以指定默认重定向。

您可以在网络配置中进行配置，一切就绪。

 <customErrors defaultRedirect="GenericError.htm" mode="On">
          <error statusCode="404" redirect="notfound.htm"/>
 </customErrors>

您可以将其配置为向所有用户或仅向远程用户等显示自定义错误页面。

http://aspnetresources.com/articles/CustomErrorPages

我完全同意您应该在 catch 块中记录所有错误并将其写入日志。

【讨论】：

【解决方案3】：

听起来您好像是在重新发明*。 ASP.NET 已经包含了一些东西来帮助你达到预期的结果。除非您需要处理逻辑以在错误后进行清理，否则我不会使用 try catch 块。查看ASP.NET Health Monitoring Overview 记录错误。至于显示自定义错误页面，请参阅How to create custom error reporting pages in ASP.NET by using Visual C# .NET。

【讨论】：

不，我不会尝试所有标准的 400+ 和 500+ 错误，我正在使用 ASP.NET 自定义错误页面，但是如果我不这样做，例如 DB 连接在这种情况下会超时'在数据访问层没有 TRY CATCH，我怎么知道那里发生了异常。
所以我实现了一个像 DBException 这样的自定义异常并将其抛出到 Global.asax 级别，并根据类型向用户显示一些消息，说明数据库连接存在一些问题服务器请告知管理员。如果 Click 事件出现问题，我会在输入方面提出一些问题。请重试或联系管理员。这是一个好方法吗？
如果您要传达有关异常的其他信息，则将异常包装在自定义异常中是一种完全可以接受的方法。但是，用户不需要知道它失败的原因，也不应该期望传达它。如果您曾经直接与用户打过交道，您就会知道他们总是会忘记消息中所说的内容。这就是为什么我建议使用标准错误页面和健康监控。您可以配置运行状况监控以记录错误详细信息。您还可以配置运行状况监控，以便在发生异常时发送电子邮件，让您更快地解决它们。

【解决方案4】：

我认为，您不需要使用异常处理。假设您有一个表示层和一个业务逻辑层/数据访问层。

在说业务逻辑中遇到错误时，它将直接移动到Application_Error事件下的Glogal.asax.cs文件，而无需返回调用函数。在这里您可以记录如下错误消息....

HttpContext.Current.Server.GetLastError().InnerException.StackTrace
HttpContext.Current.Server.GetLastError().InnerException.Message
HttpContext.Current.Server.GetLastError().InnerException.Source
HttpContext.Current.Server.GetLastError().InnerException.TargetSite.DeclaringType.FullName
HttpContext.Current.Server.GetLastError().InnerException.TargetSite.DeclaringType.Name
HttpContext.Current.Server.GetLastError().InnerException.TargetSite.DeclaringType.Namespace

现在在 Web Config 中，您可以编写代码以将用户重定向到一些默认页面，如下所示。

<customErrors defaultRedirect="ErrorPage.htm" mode="On">
   <error statusCode="404" redirect="ErrorPageNotFound.htm"/>
</customErrors>

【讨论】：