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 回答