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."或类似的结尾。我怀疑之前的工作方式不同，或者错误条件没有得到很好的测试。

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

这一般是否正常？

我复制的代码存在一些问题，但我不想重写;我只是想让它先跑，然后再发现皱纹。然而，Response.End();给我带来了精神障碍，所以我想弄清楚。

我想保留catch all子句，以防万一，至少目前如此。我也可以用以下方法结束方法：

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

但是，一旦你考虑了所有产生的异常，这看起来都非常愚蠢。

请给我一些智慧的话。如果有什么不清楚，请随时询问。谢谢！

P.S。前同事没有被解雇，并且是一个很好的程序员 - 这是重用他的榜样的另一个理由。

Answer 1

根据MSDN，所有这个调用都是停止处理并返回当前结果。因此，在处理结束时调用Response.End()应该没有效果。

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

Answer 2

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

这实际上甚至不起作用。 ThreadAbortException是一个特殊情况例外，当您的catch块完成后， it is automatically re-thrown 。

使用return绝对是最好的情况，如果您所使用的方法是根据您的代码运行的最后一件事。如果不是，并且您希望优雅地结束请求，则可以调用HttpApplication.CompleteRequest()，这将跳过处理生命周期的其余部分并直接跳转到EndRequest事件处理。

Answer 3

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

通常，您应该只捕获应该处理的异常，并且不应该向用户输出错误跟踪。由于这种奇怪的错误处理技术，只需要他正在使用的响应。

Answer 4

以这种方式查看..如果您的页面有任何其他页面方法在页面生命周期中的Page_Load之后运行（Page_Render，Page_PreRender），或者在try-catch之后还有任何其他代码 - 那么您应该离开Response.End（）到位。

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

我是否需要ASP.Net 2.0中的Response.End（）

4 个答案: