How Dangerous Is Server.Transfer?

[Guadala Harry]

I've been reading up on Server.Transfer as well as doing some testing, and
it appears to always raise the ThreadAbortException error. On one hand I've
read a bunch of promotional-type material touting the benefits of
Server.Transfer and none of them mention ThreadAbortException - but the MSDN
documentation says Server.Transfer will always cause that exception - by
design - and that the work-around is to not use Server.Transfer (and to use
Server.Execute instead). Surprising indeed. "Here's a great new tool - now
don't use it" is what I'm hearing from Microsoft about Server.Transfer. This
is confusing to me. Am I just missing something? Is ThreadAbortException
really not all that bad? I've read elsewhere that it really is bad and to
avoid it at all costs.

I'd appreciate it if anyone could clarify whether Server.Transfer is okay to
use even though it always causes a ThreadAbortException.

Thanks!

 

[Guest]

hi,

When you call Server.Transfer it terminates the currently executing thread
and goes ahead and redirects to the new page.
Since the thread is terminated a ThreadAbortException is thrown by the
runtime.

Having said that, Its perfectly fine to use Server.Transfer even if it
throws a ThreadAbortException. Just make sure you have no Try-Catch blocks
wrapping the Server.Transfer statement else the exception will keep getting
caught.

 

[Lau Lei Cheong]

You may find relevent information here.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;312629
http://blogs.msdn.com/bleroy/archive/2004/08/03/207486.aspx

 

[Guadala Harry]

The articles you provided are exactly the ones that inspired my post! The
first one is the one that explicitly states that one should NOT use
Server.Transfer and instead use Server.Execute as a workaround for "this
problem" which is also "by design".... Thus my initial confusion. We have a
situation that is created by design: I clearly understand *why*
ThreadAbortException is raised. I clearly understand that I have alternative
ways to transfer users around my application. What I'm still not sure of is
the extent to which Server.Transfer is dangerous (or not). In the second
link you provided (thank you - I should have provided those in my OP), the
author states about ending a response, "This is a very violent thing to do."
Very violent? I'll buy it - this guy seems to know his stuff and is
apparently a credible source. So, I'm wondering, if it is in fact, "very
violent," then should I ever knowingly let it happen in my application? I
think the obvious ansers is "of course you should never knowingly let a very
violent thing happen" in your application. The implication is that one
should, then, *never* user Server.Transfer because it *always* results in
the original response being terminated (which is a "very violent" thing).

Perhaps I'm just being overly cautious here (okay, paranoid). I'd really
like to know because I really like the idea of being able to use
Server.Transfer. I'm just rather uncomfortable ThreadAbortException
knowingly occuring. Is ThreadAbortException really not hurting anything; and
I would be perfectly responsible to let it happen as a matter of routine in
a busy application? I'd really like to know as Server.Transfer is otherwise
a godsend in certain situations. Thanks!

The fact that you're paranoid doesn't mean you're not being followed!

GH

 

[Scott Allen]

Hi Guadala,

I know we talked about this on another thread, and this is another one
of the reasons I still like URL rewriting as a first choice to solve
these types of problems.

However, given the chice between letting a response continue (which
could be exepensive) and aborting the response with an exception, I
imagine the team thought it might use fewer resources to throw an
exception. Obviosuly, this isn't the case in a page designed to only
do transfers or redirects.

Server.Transfer is "clean looking" from a coding point of view, but
all these approaches have some drawbacks.

 

[Lau Lei Cheong]

I think the most "dangerous" behaviour in this matter is that you may
prematurely end a cleanup algorithum in the middle. This is especially
important if you're using unsafe components that should explicitly call
cleanup yourself.

Actually, I always use Response.Redirect() so this is not a problem with me.
(The overhead to initiate another request is not considered a big problem
here.)