Response.End() 在给定场景中是强制性的吗？答案

【问题标题】：Is Response.End() mandatory in the given scenario?Response.End() 在给定场景中是强制性的吗？
【发布时间】：2011-02-01 12:47:52
【问题描述】：

string filePath = ExportAndSaveInvoiceAsHtml(invoiceId);      

Response.AddHeader("Content-Disposition", "attachment;filename=" + Path.GetFileName(filePath));

Response.WriteFile(filePath);

// Using Response.End() solves the problem
// Response.End();

我想让用户下载 HTML 发票（从发票的 gridView）。生成的文件还包含发票文件数据 + 不需要的页面 html。

如果我使用 Response.End()，它可以解决问题，但它总是抛出异常。在某些线程中读到异常是设计使然。但是可以肯定的是，它不会随时引起响应截断之类的问题吗？

我怎么能只写文件数据。

顺便说一句，之前我们将发票写成 PDF，当时没有使用 Response.End() 导致文件下载不完整。

有人可以提供将自定义数据/文件写入响应流的基础知识吗？

【问题讨论】：

标签： asp.net response.write

【解决方案1】：

这是因为响应是缓冲的。您必须调用Response.End() 来刷新缓冲区并确保客户端在处理程序线程完成之前获得完整的响应。

Response.End() 抛出的ThreadAbortException 是设计使然，可以放心地忽略。

【讨论】：

好吧，我有外部 try 块，现在因为这个异常是可忽略的，我将它包裹在 dummy try { Response.End(); } 捕捉（异常前） { Logger.LogException（前）； }
但它进入外部 catch 块也有代码向用户显示错误消息。
@Munish，恐怕我不明白：既然你吞下了异常，它不应该传播到外部范围。（另外，你应该捕获 ThreadAbortException 而不是通用的 Exception 类型）。
没错。异常不应该传播，但它似乎正在这样做。让我再测试一次，然后把结果放上来。
我找到了解决方案。看起来 ThreadAbortException 无论如何都会向上传播。链中的每个级别都需要捕获 (ThreadAbortException err) { } 以及它们已经捕获的任何异常。

【解决方案2】：

您可以使用 Response.End() 而不是

HttpContext.Current.ApplicationInstance.CompleteRequest()

这种方法倾向于避免抛出异常:)

【讨论】：

我收到编译器错误消息：CS0103：当前上下文中不存在名称“HttpContext”
奇怪的是“使用 System.Web;”可能是不明确的名称解析问题。无论如何，但编译工作使用完整路径。但功能还是一样的。仍然以文件+页面数据的形式出现。