Response.End()是否被认为是有害的？

Question

Response.End()是否被认为是有害的？这篇KB文章说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()不会被执行，这违反了最不惊讶的原则。就像Application.Exit()在WinForms应用程序中。引发的线程中止异常。Response.End()是不可捕捉的，因此将代码包围在try...finally不会满足的。这让我想知道我是否应该总是避免Response.End().有人能建议我什么时候使用Response.End()，何时Response.Close()什么时候HttpContext.Current.ApplicationInstance.CompleteRequest()?参考文献：里克·斯特拉的博客.根据我收到的信息，我的回答是，是,Response.End是有害的，但在某些有限的情况下是有用的。使用Response.End()作为不可捕获的抛出，立即终止HttpResponse在特殊情况下。在调试过程中也会很有用。避Response.End()完成例行反应.使用Response.Close()立即关闭与客户端的连接。每这篇MSDN博客文章，这种方法不适用于正常的HTTP请求处理。您不太可能有充分的理由调用此方法。使用CompleteRequest()结束正常的请求。CompleteRequest使ASP.NET管道跳转到EndRequest事件之后的HttpApplication事件完成。所以如果你打电话CompleteRequest，然后向响应写入更多内容，写将被发送到客户端。

Answer 1

如果您在应用程序上使用了异常记录器，它将使用ThreadAbortException从这些良性的Response.End()打电话。我认为这是微软的说法“别说了！”

我只会用Response.End()如果有一些特殊情况，没有其他行动是可能的。也许这样的话，记录这个异常可能实际上表示了一个警告。

Answer 2

这个问题出现在Google搜索Response.end信息的顶部，所以对于像我这样希望发布CSV/XML/PDF等响应事件而不呈现整个ASPX页面的其他搜索，我就是这样做的。(覆盖呈现方法对于这样简单的任务过于复杂，海事组织)

// Add headers for a csv file or whateverResponse.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 stringDim buffer As Byte()buffer = System.Text.Encoding.Unicode.GetBytes(csv)Response
.BinaryWrite(buffer)// Sends the response bufferResponse.Flush()// Prevents any other content from being sent to the browser
Response.SuppressContent = True// Directs the thread to finish, bypassing additional processingHttpContext.Current.ApplicationInstan
ce.CompleteRequest()