我想知道是否有必要在我调用代码隐藏return
后保留一份声明?Response.RedirectPermanent
好像不是这样,但我想和其他人确认一下。
Response.RedirectPermanent(vpd.VirtualPath);
return;
是否有任何理由这样做是为了功能或性能增益?
我想知道是否有必要在我调用代码隐藏return
后保留一份声明?Response.RedirectPermanent
好像不是这样,但我想和其他人确认一下。
Response.RedirectPermanent(vpd.VirtualPath);
return;
是否有任何理由这样做是为了功能或性能增益?
回复大修:
握住电话!经过进一步研究,我之前的回答中的细节完全不正确。事实上,MSDN 文档指定了以下内容:
当您在页面处理程序中使用此方法来终止对一个页面的请求并开始对另一个页面的新请求时,请将 endResponse 设置为 false,然后调用 CompleteRequest 方法。如果为 endResponse 参数指定 true,则此方法会为原始请求调用 End 方法,该方法在完成时会引发 ThreadAbortException 异常。此异常对 Web 应用程序性能有不利影响,这就是为什么建议为 endResponse 参数传递 false 的原因。
http://msdn.microsoft.com/en-GB/library/a8wa7sdt.aspx
所以,实际上,页面的其余部分并没有被执行(理论上 - 请参阅下面的“更新”以获取有关何时崩溃的示例);但是,按照您的方式执行此操作仍然存在一个非常明显的问题,即该endResponse
机制是通过抛出 a 来实现的ThreadAbortException
,这是一种终止当前线程处理的相对昂贵的方式。
相反,您应该告诉它让线程继续,但立即返回 - 还要确保调用堆栈中的其他方法正在执行它们应该执行的操作:
Response.RedirectPermanent(vpd.VirtualPath, false);
return;
更好的是,将调用包装在条件中以确保不会调用不需要的代码,然后使用该CompleteRequest
方法(它不会终止当前正在执行的代码,但会绕过所有后续事件):
if (_redirecting)
{
Response.RedirectPermanent(vpd.VirtualPath, false);
Context.ApplicationInstance.CompleteRequest();
}
else
{
/* Code I don't want to execute if I do a redirect */
DeleteUsersDataForever(_currentUser);
}
这里有一篇关于这个主题的深入文章,甚至文档本身似乎对方法有一种不健康的厌恶,HttpResponse.End
Response.Redirect
如果你允许为你做响应终止,这就是所谓的。
更新:此外,鉴于线程通过引发异常终止,请考虑如果您尝试在 try/catch 中执行重定向会发生什么:
try
{
// Redirect and terminate execution
Response.Redirect(someUrl, true);
}
catch
{
// Handle some errors.
}
DeleteUsersDataForever(_currentUser);
引发的异常在您的 catch 块中被Response.End
捕获。因此,您的其余代码仍会执行,并且您不小心删除了所有的数据(除非您在块中采取了一些措施来防止这种情况发生,例如将异常冒泡给调用者)。_currentUser
catch
我试过下面的代码:
第1页.aspx
protected void Page_Load(object sender, EventArgs e)
{
Response.RedirectPermanent("~/Page2.aspx");
Session["afterRedirect"] = "after redirect";
}
Page2.aspx
protected void Page_Load(object sender, EventArgs e)
{
Response.Write(Session["afterRedirect"] ?? "nothing to show");
}
结果
nothing to show
之后的代码RedirectPermanent
不会执行,因此 Iguess 是否使用 return 将具有相同的效果。