让页面方法未处理的异常表现为其他 ASP.Net 未处理的异常答案

【问题标题】：Have Page Method Unhandled Exceptions Behave as Other ASP.Net Unhandled Exceptions让页面方法未处理的异常表现为其他 ASP.Net 未处理的异常
【发布时间】：2012-10-28 22:25:09
【问题描述】：

我有一个具有单页方法的网络表单。我的其他 Web 应用程序将未处理的异常记录到 Web 服务器上的系统事件日志中。由于与我合作的其他开发人员希望在事件日志中看到应用错误条目，因此我希望此应用也能这样做。

但是，当从页面方法中调用代码捕获异常时，我让应用程序发送错误电子邮件。发生这种情况时，它不会写入事件日志。注意：页面方法调用我的邮件通知方法后重新抛出异常。

从我目前所读到的内容看来，ASP.Net 默认将错误记录到事件日志中。我想页面方法/WebMethods 的情况并非如此，因为它们基本上将异常抛出给调用它的客户端代码。

是否有一种简单的方法可以使该异常正确冒泡以便写入事件日志？没有其他应用程序直接根据我所看到的内容写入事件日志，因此我认为该应用程序不会创建新源，因为我们的安全人员将很多事情锁定（出于善意，是的安全）。

[WebMethod]
public static object MyPseudoWebMethod()
{
    try
    {
        // My exception spawning unreliable code here
    }
    catch(Exception ex)
    {
        // Cleanup ...
        this.SendErrorNotification(ex);

        throw; // <-- This doesn't bubble up but I'd love for it to!
    }
}

【问题讨论】：

您确定这没有像其他异常一样得到处理吗？我假设您的应用程序会像处理其他任何错误一样处理该错误，唯一的区别是客户端页面不会明显改变。但是在 AJAX 调用之后，webmethod 会抛出异常，这会使 AJAX 响应成为 YellowScreenOfDeath 或您拥有的任何自定义错误页面，并且所有后续代码都将由此类自定义错误页面执行。
错误日志不包含异常，但它包含来自其他应用程序的异常。不过，AJAX 调用不会呈现黄色死屏。页面已经加载，客户端javascript调用webmethod，webmethod抛出异常，客户端javascript检测到错误但事件日志中没有记录异常。
你有一个“只有一个 WebMethod 的网络表单”？
做了一些研究......好吧，你是正确的 jlafay，但不是 100%。 WebMethods 有一个特殊性，即 XML Web 服务的 HTTP 处理程序在异常到达 global.asax 之前将其吞下，但“正常”AJAX 调用不遵循该模式。因此，如果它不是一个 WebMethod，而只是一个返回字符串或其他内容的 ASPX 页面，它将在日志记录方面与其他页面一样处理异常。我会想办法解决这个问题。
@JohnSaunders，是的。这是我有时会做的一个项目。这是一个非常简单的内部网络应用程序。它是一个 Web 表单，其背后的代码有一个 WebMethod，它调用 WCF 服务，该服务是我们中间层的一部分，用于检索实体以传回给客户端。

标签： asp.net exception-handling asmx webforms pagemethods

【解决方案1】：

嗯，有趣的问题。你是对的，WebMethod 异常不遵循正常的异常流程。

如果您的 Web 方法抛出一个错误，则不会触发 Application_Error 事件例外。原因是 XML Web 的 HTTP 处理程序 services 使用 XML Web 服务时发生的任何异常正在执行并将其转换为 SOAP 错误之前调用 Application_Error 事件。

（来自here）

上面的页面建议使用 SOAP 扩展在异常被吞下之前捕获它，但如果你不想这样做，我会这样做：

1) 创建一个新的“错误接收”ASPX 页面，您将构建该页面将采用您想要在错误日志中记录的任何参数。因此，例如，让此页面接收名为“ExceptionDetails”的 POST 或您希望捕获的任何其他内容。此页面不会直接在浏览器中查看，因此它不需要任何 ASPX 控件或任何东西，但在其上使用 MasterPage 不会造成任何损害。

2) 在这个新页面后面的代码中，获取您发送的任何 POSTS，并使用您需要的任何详细信息新建一个异常。立即抛出此异常。这样做意味着此异常将遵循应用程序中其他未处理异常的任何流程（日志记录、电子邮件发送等）。

3) 在调用 WebMethod JS 的页面上，将对 WebMethod 的调用包装在 try-catch 中

4) 在 catch 块中，在浏览器中打印出您想要的任何消息，并向接收 ASPX 页面的新错误发起一个新的 AJAX 发布，并传递您让该页面寻找的任何 POST 内容。

默认情况下，新的 AJAX 调用不会改变用户的感知。 AJAX 调用会触发对该页面的新请求，而 ASPX 页面本身实际上完全不知道它的 AJAX 而不是正常的浏览器请求。如果您正在记录用户 ID 或其他任何内容，那么当前设置的任何 cookie/会话/身份验证数据也可用于 AJAX 页面。如果您查看像 Firebug 这样的工具返回的响应，您会发现它实际上是 YellowScreenOfDeath 的 HTML（除非您有一个自定义的 500 页面，在这种情况下，它是返回的那个 HTML）。

【讨论】：

【解决方案2】：

这就是传统 ASMX Web 服务的工作原理。

唯一的解决方法是停止使用它们（无论如何你都应该这样做，除非你被 .NET 2.0 卡住了）。 WCF 没有这个问题。

【讨论】：

这是我最近开发的一个旧应用程序。一般来说，我更喜欢 WCF 而不是这种类型的行为，但我认为对于这种情况可能没问题。主要是因为它是一种方法，它仍然有效，而且对于这样一个简单的应用程序，WCF 配置地狱不是必需的。
从 .NET 4.0 开始，WCF 配置地狱不再存在，顺便说一句。
我认为这是一个见仁见智的问题 :) 我知道它不是同一种动物，因为它仅限于 HTTP 用于协议选择，但我对 Web API 的配置和易于实施感到更满意。