views:

2204

answers:

5

I have Default.aspx page, which inherits from BasePage.cs, which inherits from System.Web.UI.Page. BasePage is where I do some common things every page must do upon loading.

In BasePage, lets say I'm checking for X. If X=1, then I will redirect to my "Discontinued.aspx" page immediately and stop execution of BasePage. If I find X=1, I say:

HttpContext.Current.Response.Redirect("Discontinued.aspx", true);

I want the redirect to stop execution of BasePage and immediately jump out - hence the "true" in the above statement - which should stop execution of the current page as I understand. The problem is, it doesn't. I'm expecting the redirect to throw the "thread abort exception".

When I run in debug mode, it contines stepping through as though it didn't just redirect and leave.

But the redirect was still started as well - once I get done stepping through the rest of BasePage, the "Discontinued" page then begins to load as a result of the redirect.

Is there a reason my Redirect will not kill execution of BasePage?

+2  A: 

are you exiting from the function that calls redirect, e.g.

...redirect(stopit,true);
return;

?

Steven A. Lowe
I added a "return;" after Response.Redirect and that jumped me out of the function, and accomplished what I wanted I think. So thanks.
Chad
+1  A: 

Probably you are calling the Response.Redirect method inside a try{}catch{} block, try it by calling outside of this block and you'll see that it will not fail. More info: http://www.velocityreviews.com/forums/t72105-responseredirect-in-a-trycatch.html Hope this helps.

Jaime Febres
Better yet:<code>HttpContext.Current.Response.Redirect("Discontinued.aspx", false);return;</code>Hope this helps.
Jaime Febres
In other places in my app, I do expect the System.Threading.ThreadAbortException, and can simply handle it by doing nothing. So I'm not afraid of this exception - in fact, it's what I expected and wantd. It just wouldn't throw it...perhaps because I'm in BasePage and not the aspx?
Chad
By the way, as you see above your second thought turned out to be the way to go. Thanks.
Chad
Cool, happy that you found an answer.Cheers.
Jaime Febres
A: 

For an unconditional termination, you could try a

Response.End()
recursive
I tried this one first, but it didn't seem to stop anything. Thanks for the thought though.
Chad
+1  A: 

I'm going to get down voted for this! Curse my ignorance...

Obviously you could try adding the following line after the redirect (as pointed out by recursive),

response.end()

But maybe the reason the response.redirect is not immediately causing redirection is that you have response buffering on (the default) and the page processing is not ended until after the buffer is flushed. If this were true (and admittedly I'm to lazy too try) then adding the following line would also solve you problem.

response.flush()
Christopher Edwards
read my response....
Shawn Simon
I do have "HttpContext.Current.Response.BufferOutput = true;" in there, so you could be right. The Response.End() didn't stop anything, so I had to go with the "return;" option.
Chad
+6  A: 

The second parameter for Response.Redirect is endResponse, however the tooltip says 'Indicates whether execution of the current page should terminate'. This is misleading, because the execution of the page does not actually terminate when the variable is true. It will finish running any code. However what does happen differently, is the Render events are canceled, and the Response is immediately flushed with the object moved header.

You need to manually exit out of any methods, Response.Redirect / Response.End will not do that for you. Futhermore, if you need a conditional to see if the Page has been redirected, check out Response.IsRequestBeingRedirected.

Shawn Simon
Good stuff to know - thanks. Foiled by an inaccurate tooltip!
Chad
good answer - except you forgot to mention that you have to return out of the function after the redirect ;-)
Steven A. Lowe
yes. except, you don't always want to do that
Shawn Simon