HttpResponse.End Method
.NET Framework 2.0
Sends all currently buffered output to the client, stops execution of the page, and raises the EndRequest event.
Namespace: System.Web
Assembly: System.Web (in system.web.dll)
Assembly: System.Web (in system.web.dll)
The following code example uses the IsClientConnected property to check whether the client requesting the page remains connected to the server. If IsClientConnected is true, the code calls the Redirect method, and the client will view another page. If IsClientConnected is false, the code calls the End method and all page processing is terminated.
<%@ Page Language="C#" %> <script runat="server"> private void Page_Load(object sender, EventArgs e) { // Check whether the browser remains // connected to the server. if (Response.IsClientConnected) { // If still connected, redirect // to another page. Response.Redirect("Page2CS.aspx", false); } else { // If the browser is not connected // stop all response processing. Response.End(); } } </script> <html> <head> </head> <body> <form runat="server"> </form> </body> </html>
Windows 98, Windows 2000 SP4, Windows Server 2003, Windows XP Media Center Edition, Windows XP Professional x64 Edition, Windows XP SP2, Windows XP Starter Edition
The .NET Framework does not support all versions of every platform. For a list of the supported versions, see System Requirements.
Doesn't ALWAYS throw ThreadAbortException!
Actually, putting aside the discussion of whether it should throw the exception, it does NOT always do so. The exception will only be thrown if you are in a cancellable execution step. A page is cancellable, but global.asax is NOT. So if you do a redirect in Global.asax processing will continue for the rest of that method even if you pass true. Look at Response.End w/reflector if you don't believe me. :)
- 3/27/2008
- WaldenL
This shouldn't cause a ThreadAbortException
The fact that End always throws a ThreadAbortException runs counter to conventional wisdom about only throwing exceptions under exceptional situations. Calling a public method is hardly exceptional!
The design guidelines seem willing to accept this usage though:
"Do not use exceptions for normal flow of control, if possible"
It would be nice to look for alternatives to the current implementation. Just some food for thought.
The design guidelines seem willing to accept this usage though:
"Do not use exceptions for normal flow of control, if possible"
It would be nice to look for alternatives to the current implementation. Just some food for thought.
- 8/31/2006
- Karl Seguin - MVP