我需要 ASP.Net 2.0 中的 Response.End()

Question

我刚刚开始使用 ASP.Net。我复制了前同事的代码（来自 .Net 1.1 时代），它有一个 Response.End(); 以防出现错误。 还有一个：，

        catch (Exception ex)
        {
            Response.Write(ex.Message);
            Response.End();
        }

在 Page_Load(object sender, System.EventArgs e) 的末尾 它总是在末尾附加 “Thread was aborted.” 或类似的内容。我怀疑这之前的工作方式有所不同，或者错误条件没有经过很好的测试。

无论如何，当我不喜欢 GET 参数时，我可以停止使用 Response.End(); ，并使用 return;反而。在一个简单的案例中，它似乎做出了正确的思考。

总体来说这样可以吗？

我复制的代码有一些问题，但我不想重写；我只想先让它运行起来，然后再发现皱纹。然而，Response.End(); 给我造成了心理障碍，所以我想弄清楚它。

我想保留一揽子条款以防万一，至少现在是这样。我也可以用以下内容结束该方法：

        catch (System.Threading.ThreadAbortException)
        {
            Response.End();
        }
        catch (Exception ex)
        {
            Response.Write(ex.Message);
            Response.End();
        }

但是，一旦您考虑到生成的所有异常，这似乎非常愚蠢。

请给我几句智慧的话。如果有不清楚的地方，请随时询问。谢谢！

PS 前同事没有被解雇，并且是一名优秀的编码员 - 这是重复使用他的示例的又一个原因。

Answer 1

 catch (System.Threading.ThreadAbortException)
    {
        Response.End();
    }
    catch (Exception ex)
    {
        Response.Write(ex.Message);
        Response.End();
    }

这实际上根本行不通。 ThreadAbortException 是一种特殊情况的异常，当您的 catch 块完成时，它会自动重新抛出。

如果您所在的方法是代码中最后运行的方法，那么仅使用 return 绝对是最好的情况。如果不是，并且您想正常结束请求，可以调用 HttpApplication.CompleteRequest()，它将跳过生命周期剩余部分的处理，直接跳转到 EndRequest 事件处理。

Answer 2

根据 MSDN，所有这些调用所做的就是停止处理并返回当前结果。因此，在处理结束时调用 Response.End() 应该不会产生任何效果。

在实践中，我只用它来中止当前的处理。

Answer 3

您不应该在此级别捕获所有异常。使用 global.asax 中的 Application_Error 事件来处理意外错误并提供自定义错误页面以向您的客户端显示（请参阅 web.config 中的 customError 部分）。

一般来说，您应该只捕获应该处理的异常，并且不应该向用户输出错误跟踪。由于这种奇怪的错误处理技术，他所使用的response.end 才被需要。

Answer 4

这样看.. 如果您的页面在页面生命周期中的 Page_Load 之后运行任何其他页面方法（Page_Render、Page_PreRender），或者如果在 try-catch 之后直接有任何其他代码 - 那么您应该保留 Response。 End() 就位。

如果没有类似的情况 - 那么您可以根据需要删除它们，不会发生任何不同的情况。但考虑到这是一个旧的内部（甚至可能是遗留的？从 .NET 1.1 复制的）应用程序，而不是您自己编写的，您可能可以将它们保留在原处。它们绝对不会造成伤害，并且可能会帮助您避免难以发现的奇怪问题，这些问题通常在旧版应用程序中发现：D