.net Response.End（）被认为是有害的吗？

表示ASP.NET的

Response.End（）

中止线程

反射器显示它看起来像这样：

public void End()
{
    if (this._context.IsInCancellablePeriod)
    {
        InternalSecurityPermissions.ControlThread.Assert();
        Thread.CurrentThread.Abort(new HttpApplication.CancelModuleException(false));
    }
    else if (!this._flushing)
    {
        this.Flush();
        this._ended = true;
        if (this._context.ApplicationInstance != null)
        {
            this._context.ApplicationInstance.CompleteRequest();
        }
    }
}

这对我来说似乎很苛刻。正如KB文章所说，应用程序中任何遵循

Response.End（）

的代码都不会被执行，这违反了最小惊讶原则。这几乎就像WinForms应用程序中的

Application.Exit（）

。

Response.End（）

导致的线程中止异常不可捕获，因此在

try

..

中包围代码将无法满足要求

这让我想知道我是否应该总是避免
Response.End（）

有人能建议我何时使用
Response.End（）
，何时使用
Response.Close（）
，何时使用
HttpContext.Current.ApplicationInstance.CompleteRequest（）

参考号：


根据我收到的输入，我的答案是，是，
响应。End
是有害的，但在某些有限的情况下是有用的


使用
Response.End（）
作为不可修补的抛出，在异常情况下立即终止
HttpResponse
。在调试期间也可能有用。避免使用
Response.End（）
来完成例行响应
使用
Response.Close（）
立即关闭与客户端的连接。根据，此方法不适用于正常的HTTP请求处理。您不太可能有充分的理由调用此方法
使用
CompleteRequest（）
结束正常请求
CompleteRequest
导致ASP.NET管道在当前的
HttpApplication
事件完成后跳转到
EndRequest
事件。因此，如果调用
CompleteRequest
，然后在响应中写入更多内容，则写入内容将发送到客户端


编辑日期：2011年4月13日

此处提供了进一步的说明：




我从未考虑过使用Response.End（）来控制程序流

但是，Response.End（）在向用户提供文件时非常有用

您已将文件写入响应，不希望向响应中添加任何其他内容，因为它可能会损坏您的文件。
我以前在.NET和Classic ASP中都使用了response.End（）来强制结束操作。例如，我在有一定数量的登录尝试时使用它。或者从未经验证的登录访问安全页面时（粗略示例）：

当向用户提供文件时，我会使用刷新，最终可能会导致问题
 如果您在应用程序上使用了异常记录器，则这些良性
Response.End（）
调用中的
ThreadAbortException
s会淡化该异常记录器。我认为这是微软的说法“住手！”

只有在出现某些异常情况且无法执行其他操作时，我才会使用
Response.End（）
。那么，记录此异常可能实际上表明存在警告。
我只使用Response.End（）作为测试/调试机制

<snip>
Response.Write("myVariable: " + myVariable.ToString());
Response.End();
<snip>


Write（“myVariable:+myVariable.ToString（））；
Response.End（）；

从你在研究方面发布的内容来看，如果它需要回应，我会说这是一个糟糕的设计。End
我不同意“Response.End是有害的”这句话。这绝对没有害处。回应。结束做它所说的；它结束页面的执行。使用reflector查看它是如何实现的，只应被视为具有指导意义


我的推荐信

避免使用
Response.End（）
作为控制流。

如果需要停止请求执行并注意（通常）*没有代码会执行超过该点，请使用
Response.End（）


*
Response.End（）
和s

Response.End（）

ThreadAbortException是一个可以捕获的特殊异常，但是
它将在挡块末端再次自动升起

若要了解如何编写必须处理ThreadAbortException的代码，请参阅@Mehrdad对SO的回复，以了解他引用和引用的位置


上述内容很有启发性，请务必阅读评论。请注意，斯特拉尔的问题是具体的。他希望将数据发送到客户端（一个图像），然后处理命中跟踪数据库更新，这不会减慢图像的服务速度，这使得他的问题在于在响应后做些什么。End被调用。
关于“我仍然不知道响应。Close和CompleteRequest（）之间的区别”的问题我想说：

请选择CompleteRequest（），不要使用Response.Close（）

有关此案例的详细摘要，请参见

请注意，即使在调用CompleteRequest（）之后，一些文本（例如，从ASPX代码中重新绘制的文本）也会附加到响应输出流中。可以通过重写Render和RaisePostBackEvent方法来防止它，如中所述

顺便说一句：我同意禁止使用Response.End（），尤其是在将数据写入http流以模拟文件下载时。我们过去一直使用Response.End（），直到日志文件中充满了ThreadAbortException。
TL；博士
最初，我建议您只需将所有呼叫替换为
[Response.End]使用[…]CompleteRequest（）调用，但如果要避免
回发处理和html呈现您需要添加[…]覆盖作为
嗯

“最终分析”


根据MSDN和Alain Renon：
Server.Transfer、Response.Redirect、Response.End方法都会引发
例外情况。每个方法都在内部调用Response.End。呼吁
响应。依次结束

HttpApplication.CompleteRequest（）设置一个变量，使线程
跳过米
<snip>
Response.Write("myVariable: " + myVariable.ToString());
Response.End();
<snip>

// Add headers for a csv file or whatever
Response.ContentType = "text/csv"
Response.AddHeader("Content-Disposition", "attachment;filename=report.csv")
Response.AddHeader("Pragma", "no-cache")
Response.AddHeader("Cache-Control", "no-cache")

// Write the data as binary from a unicode string
Dim buffer As Byte()
buffer = System.Text.Encoding.Unicode.GetBytes(csv)
Response.BinaryWrite(buffer)

// Sends the response buffer
Response.Flush()

// Prevents any other content from being sent to the browser
Response.SuppressContent = True

// Directs the thread to finish, bypassing additional processing
HttpContext.Current.ApplicationInstance.CompleteRequest()