Threadabortexception

[Anushya]

Hi
When i abort a thread i get threadabort exception and wot all the
things that need to be done there? IS releasing all the objects that
are created is necesssary before aborting?Or aborting alone is
sufficient?

Join ing the thread till it is killed is impossible in my scenario as
the exception is routed to some other layer. In the layer where abort
is done, the user will not handle it..
THanks
ANu

[David Levine]

"Anushya" <v_*******@hotmail.com> wrote in message
news:80**************************@posting.google.c om...

Hi
When i abort a thread i get threadabort exception and wot all the
things that need to be done there? IS releasing all the objects that
are created is necesssary before aborting?Or aborting alone is
sufficient?
It sounds like you are confusing the roles of a number of different
mechanisms. Aborting a thread injects an abort exception into the target
thread. If the abort is injected into the thread from a different thread
then it is injected asynchronously and it can interrupt a number of
execution paths, such as finally blocks and static constructors, that you
really don't want interrupted. If it is thrown by itself then it is
synchronous and so long as you understand the consequences it should not
cause harmful side-effects.

The abort causes an exception to be raised, and even if a catch block handle
the exception, once the catch block body is exited the exception will be
rethrown so the next higher catch block sees it, until all catch (and
finally) blocks have run. Eventually the thread returns from its start
method and the thread terminates.

By itself an abort does not clean up any resources nor does it call Dispose
on objects. All it does is execute catch and finally blocks until the thread
exits or the abort is reset. If you need cleanup logic then you must write
code for it.

Aborting a thread is usually not a good thing to do as it has side-effects
that can be harmful - do not use it unless you know that you wont get bit by
the side-effects. There are other methods you can use to cause a thread to
terminate, such as setting a field, signalling an event, etc. that the
thread periodically checks and if set causes it to return from its thread
start method. Also, if the thread is executing unmanaged code the abort will
not take affect until the thread returns from the unmanaged code and begins
executing managed code again.

Join ing the thread till it is killed is impossible in my scenario as
the exception is routed to some other layer. In the layer where abort
is done, the user will not handle it..

This does not make sense. Does the other layer control the thread? A
different design would be preferable to that. What would the user do to
handle an abort exception?

[Anushya]

Thankss David,
But u say exception is rethrown from the point of abortion to start
method. In that case in huge products with lots of components inside,
we will be processing different objects which spans around hundreds of
classes.. Then in this case it is almost impossible to handle the
exception in all the methods in all the classes.. Worser may be the
sitn really, as i am talking of a single thread execution path in this
context..

The abort causes an exception to be raised, and even if a catch block handle
the exception, once the catch block body is exited the exception will be
rethrown so the next higher catch block sees it, until all catch (and
finally) blocks have run. Eventually the thread returns from its start
method and the thread terminates. So do u say the only soln is synchronous... In that case too from one
start method, the flow is again lengthy one and when the thread
aborts, the point is somewhere in some method.. how can i handle it?
even if i run a thread in background to check for the flag, how can i
return from that unknown method in unknown class????There are other methods you can use to cause a thread to
terminate, such as setting a field, signalling an event, etc. that the
thread periodically checks and if set causes it to return from its thread
start method. Many Thanks
Anushya

"David Levine" <no****************@wi.rr.com> wrote in message news:<ef**************@TK2MSFTNGP10.phx.gbl>... "Anushya" <v_*******@hotmail.com> wrote in message
news:80**************************@posting.google.c om...

Hi
When i abort a thread i get threadabort exception and wot all the
things that need to be done there? IS releasing all the objects that
are created is necesssary before aborting?Or aborting alone is
sufficient?

It sounds like you are confusing the roles of a number of different
mechanisms. Aborting a thread injects an abort exception into the target
thread. If the abort is injected into the thread from a different thread
then it is injected asynchronously and it can interrupt a number of
execution paths, such as finally blocks and static constructors, that you
really don't want interrupted. If it is thrown by itself then it is
synchronous and so long as you understand the consequences it should not
cause harmful side-effects.

The abort causes an exception to be raised, and even if a catch block handle
the exception, once the catch block body is exited the exception will be
rethrown so the next higher catch block sees it, until all catch (and
finally) blocks have run. Eventually the thread returns from its start
method and the thread terminates.

By itself an abort does not clean up any resources nor does it call Dispose
on objects. All it does is execute catch and finally blocks until the thread
exits or the abort is reset. If you need cleanup logic then you must write
code for it.

Aborting a thread is usually not a good thing to do as it has side-effects
that can be harmful - do not use it unless you know that you wont get bit by
the side-effects. There are other methods you can use to cause a thread to
terminate, such as setting a field, signalling an event, etc. that the
thread periodically checks and if set causes it to return from its thread
start method. Also, if the thread is executing unmanaged code the abort will
not take affect until the thread returns from the unmanaged code and begins
executing managed code again.

Join ing the thread till it is killed is impossible in my scenario as
the exception is routed to some other layer. In the layer where abort
is done, the user will not handle it..

This does not make sense. Does the other layer control the thread? A
different design would be preferable to that. What would the user do to
handle an abort exception?

[David Levine]

"Anushya" <v_*******@hotmail.com> wrote in message
news:80*************************@posting.google.co m...

Thankss David,
But u say exception is rethrown from the point of abortion to start
method. In that case in huge products with lots of components inside,
we will be processing different objects which spans around hundreds of
classes.. Then in this case it is almost impossible to handle the
exception in all the methods in all the classes.. Worser may be the
sitn really, as i am talking of a single thread execution path in this
context..

That isn't quite what I said, and it isn't clear what you are asking.

The abort causes an exception to be raised, and even if a catch block handle the exception, once the catch block body is exited the exception will be
rethrown so the next higher catch block sees it, until all catch (and
finally) blocks have run. Eventually the thread returns from its start
method and the thread terminates.

So do u say the only soln is synchronous... In that case too from one
start method, the flow is again lengthy one and when the thread
aborts, the point is somewhere in some method.. how can i handle it?
even if i run a thread in background to check for the flag, how can i
return from that unknown method in unknown class????

No, I am not stating that you must use it synchronously, just that doing so
is preferred because injecting an abort asynchronously has side-effects that
can cause problems.

Do you want to interrupt a thread that is executing code written by
yourself and over which you have control, or are you trying to arbitrarily
interrupt a thread executing code written by an unknown third party where
you do not know what the code is actually doing? Also, the execution state
of a thread is completely unrelated to the state of other objects. If you
need certain objects to be cleaned up when the thread is terminated then you
will have to write the code yourself to make this happen.

It isn't at all clear to me what you are trying to accomplish.