They are really quite different constructs. Response.Redirect involves an extra round-trip to the browser, which obviously has quite a high overhead (a lot higher than throwing a couple of exceptions), however it will cause the correct url to be shown in the browser (can be important if you want the page to be bookmarkable) and to be logged in the IIS logs. It's also 'cleaner' in that the destination page is running as a fresh request.
Mark. -----Original Message----- From: Brian Boyd [mailto:[EMAIL PROTECTED] Sent: 05 October 2004 21:11 To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Server.Transfer vs. Response.Redirect Thanks J. I understand that exceptions aren't cheap, but what I find is that even when I include 'false' as the second parameter, this exeption is still thrown. I'm running v1.1. I would be happy to avoid that exception if you or anyone else has ideas. ... this area is still confusing to me in trying to resolve what I see and what I've read. Thanks again, Brian p.s. In reading through the Microsoft Performance Guidelines, they recommend the Server.Transfer approach over Response.Redirect, even though the throwing of this exception is an expected result of calling this. -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] Behalf Of J. Merrill Sent: Tuesday, October 05, 2004 12:34 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Server.Transfer vs. Response.Redirect There's no reason to do what you've got below vs passing False as the 2nd parameter to Server.Transfer. It's not cheap to have the system generate, then catch, an exception. At 01:57 PM 10/5/2004, Brian Boyd wrote >What I do is catch the ThreadAbortException and then do a >Thread.ResetAbort(): > > try > { > Server.Transfer(newURL); > } > catch(ThreadAbortException) > { > //We're expecting this to be thrown. > Thread.ResetAbort(); > } > catch(Exception e) > { > //Catch other stuff. > ... > } > >So, you don't have to worry 'buot a 'run-away' exception. I use >Server.Transfer so that the page context handler of the sending page is >still available within the receiving page's Page_Load. So far, so good. > >I'm still learning the ins and outs of .NET, so are there any issues >with this? > >-----Original Message----- >From: Unmoderated discussion of advanced .NET topics. >[mailto:[EMAIL PROTECTED] Behalf Of Mark White >Sent: Tuesday, October 05, 2004 10:10 AM >To: [EMAIL PROTECTED] >Subject: Re: [ADVANCED-DOTNET] Server.Transfer vs. Response.Redirect > > >When the second parameter of Response.Redirect (endResponse) is true >(which it is by default), the ASP.NET framework needs to stop execution >of the current page. It does this by throwing a ThreadAbortException. > >This is therefore expected and not harmful, and is not a reason to use >Server.Transfer instead. However there are a couple of things to be >aware of. > >You can prevent the exception from throwing in the first place by >setting endResponse to false. In this case remember that code below >the Response.Redirect will execute after the redirect - so make sure >that there's no code there you don't want to execute. > >Also if you are catching the exception be aware that >ThreadAbortException is special in the CLR - it will be rethrown after >a try ... catch block, so even if you're catching the exception >locally, the Page_Error event may be still be triggered. If you have a >Page_Error handler it's best to ignore ThreadAbortException. > >Mark. > >-----Original Message----- >From: Jesse Sanders [mailto:[EMAIL PROTECTED] >Sent: 05 October 2004 17:51 >To: [EMAIL PROTECTED] >Subject: [ADVANCED-DOTNET] Server.Transfer vs. Response.Redirect > >Some time ago I switched from using Response.Redirect to using >Server.Transfer because of a thread abort error that kept occurring. >After searching on the error, I found a Microsoft article explaining >this error was expected and that I should use server.transfer. The >biggest thing we lost by using server.transfer was the ability to look >at the context of the prior page which resulted in putting everything >on the querystring. > >Now, we are looking to switch back to response.redirect due to other >reason revolving around our security objects-when we use >server.transfer and check the url object, it still says we are on the previous page... >not so good when we are checking security to see if the user has rights >to this page. I can't change the security model... its not even an >option, so I need to make sure that when I run this code: strPageName = >.Request.Url.Segments(oURI.Segments.Length - 1) that it tells me the >correct name of the current page. > >Are there any reasons to not use response.redirect? I figure we will >trap for the threading abort error and ignore it, but I was hoping to >get a consensus on the pros and cons. It would be my preference to use >response.redirect, but the error sort of wigs me out. > >Thanks, > >Jesse Sanders J. Merrill / Analytical Software Corp =================================== This list is hosted by DevelopMentor(r) http://www.develop.com Some .NET courses you may be interested in: Essential .NET: building applications and components with CSharp August 30 - September 3, in Los Angeles http://www.develop.com/courses/edotnet View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor(r) http://www.develop.com Some .NET courses you may be interested in: Essential .NET: building applications and components with CSharp August 30 - September 3, in Los Angeles http://www.develop.com/courses/edotnet View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor� http://www.develop.com Some .NET courses you may be interested in: Essential .NET: building applications and components with CSharp August 30 - September 3, in Los Angeles http://www.develop.com/courses/edotnet View archives and manage your subscription(s) at http://discuss.develop.com
