468,771 Members | 1,435 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,771 developers. It's quick & easy.

How Dangerous Is Server.Transfer?

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!
Nov 18 '05 #1
5 2333
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.
Nov 18 '05 #2
You may find relevent information here.
http://support.microsoft.com/default...b;EN-US;312629
http://blogs.msdn.com/bleroy/archive...03/207486.aspx

"Guadala Harry" <GM**@NoSpam.com> 秎ン
news:en**************@TK2MSFTNGP12.phx.gbl い级糶...
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!

Nov 18 '05 #3
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


"Lau Lei Cheong" <le****@yehoo.com.hk> wrote in message
news:ON**************@TK2MSFTNGP10.phx.gbl...
You may find relevent information here.
http://support.microsoft.com/default...b;EN-US;312629
http://blogs.msdn.com/bleroy/archive...03/207486.aspx

"Guadala Harry" <GM**@NoSpam.com> 秎ン
news:en**************@TK2MSFTNGP12.phx.gbl い级糶...
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!


Nov 18 '05 #4
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.

--
Scott
http://www.OdeToCode.com/

On Fri, 8 Oct 2004 05:33:33 -0700, "Guadala Harry" <GM**@NoSpam.com>
wrote:
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


"Lau Lei Cheong" <le****@yehoo.com.hk> wrote in message
news:ON**************@TK2MSFTNGP10.phx.gbl...
You may find relevent information here.
http://support.microsoft.com/default...b;EN-US;312629
http://blogs.msdn.com/bleroy/archive...03/207486.aspx

"Guadala Harry" <GM**@NoSpam.com> 秎ン
news:en**************@TK2MSFTNGP12.phx.gbl い级糶...
> 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 andto > 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!
>
>



Nov 18 '05 #5
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.)

"Guadala Harry" <GM**@NoSpam.com> 秎ン
news:uE*************@TK2MSFTNGP11.phx.gbl い级糶...
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


"Lau Lei Cheong" <le****@yehoo.com.hk> wrote in message
news:ON**************@TK2MSFTNGP10.phx.gbl...
You may find relevent information here.
http://support.microsoft.com/default...b;EN-US;312629
http://blogs.msdn.com/bleroy/archive...03/207486.aspx

"Guadala Harry" <GM**@NoSpam.com> 秎ン
news:en**************@TK2MSFTNGP12.phx.gbl い级糶...
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!



Nov 18 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Harsh Thakur | last post: by
9 posts views Thread by Mark | last post: by
11 posts views Thread by Alexander Bosch | last post: by
8 posts views Thread by bryan | last post: by
6 posts views Thread by n# | last post: by
2 posts views Thread by =?Utf-8?B?YWxiZXJ0b3Nvcmlh?= | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.