1

我刚开始使用 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 (System.Threading.ThreadAbortException)
        {
            Response.End();
        }
        catch (Exception ex)
        {
            Response.Write(ex.Message);
            Response.End();
        }

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

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

PS 前同事没有被解雇，并且是一名优秀的编码员 - 重用他的例子的另一个理由。

4

4 回答 4

3

根据MSDN，此调用所做的只是停止处理并返回当前结果。因此，在处理结束时调用Response.End()应该无效。

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

于 2010-04-20T15:58:45.493 回答
3 
 catch (System.Threading.ThreadAbortException)
    {
        Response.End();
    }
    catch (Exception ex)
    {
        Response.Write(ex.Message);
        Response.End();
    }

这实际上甚至行不通。 ThreadAbortException是一个特例异常，当你的 catch 块完成时，它会自动重新抛出。

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

于 2010-04-20T16:36:47.627 回答
1

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

一般来说，你应该只捕获你应该处理的异常，你不应该向你的用户输出错误跟踪。由于这种奇怪的错误处理技术，他正在使用的 response.end 只是必需的。

于 2010-04-20T15:55:51.993 回答
1

这样看.. 如果您的页面在页面生命周期中在 Page_Load 之后运行任何其他页面方法（Page_Render、Page_PreRender），或者如果在 try-catch 之后直接有任何其他代码 - 那么您应该离开响应。结束（）到位。

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

于 2010-04-20T16:24:20.373 回答