473,396 Members | 2,061 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,396 software developers and data experts.

ThreadAbortException occurs when the child thread is in catch block{}

If a childThread is in the middle of a catch block and handling an
exception caught, the main thread calls childThread.Abort(). At that
time a ThreadAbortException is thrown in the childThread. The question
is: after the ThreadAbortException is thrown, does the childThread
continue run the remaining code in the catch block?

Oct 12 '06 #1
6 7417
If a childThread is in the middle of a catch block and handling an
exception caught, the main thread calls childThread.Abort(). At that
time a ThreadAbortException is thrown in the childThread. The
question is: after the ThreadAbortException is thrown, does the
childThread continue run the remaining code in the catch block?
I don't think the code in the child thread's catch block will continue to
run. The documentation for Thread.Abort() mentions that, in .NET Framework
version 2.0, code in finally blocks will execute but it does not mention
catch blocks. You could test this be signalling the thread that aborts the
child thread from the child thread's catch block and then performing the
Abort and determining if the code after the signal is executed.

Best Regards,
Dustin Campbell
Developer Express Inc.
Oct 12 '06 #2
It looks like the catch-block will be executed just like a finally block
will. Here's a sample console application that you can use to test this behavior:

using System;
using System.Threading;

namespace ThreadTest
{
class Program
{
static ManualResetEvent resetEvent = new ManualResetEvent(false);

static void ThreadProc()
{
string text = null;
try
{
Console.WriteLine(text.ToString());

Console.WriteLine("ThreadProc(): Code at end of try");
}
catch (NullReferenceException)
{
Console.WriteLine("ThreadState at start of catch-block: {0}", Thread.CurrentThread.ThreadState);
resetEvent.Set();
Thread.Sleep(1000);
Console.WriteLine("ThreadState at end of catch-block: {0}", Thread.CurrentThread.ThreadState);
}
finally
{
Console.WriteLine("ThreadProc(): finally-block executed");
}

Console.WriteLine("ThreadProc(): Code after finally-block");
}
static void Main(string[] args)
{
Thread t = new Thread(ThreadProc);
t.Start();
resetEvent.WaitOne();
t.Abort();
Console.WriteLine("Main(): Thread.Abort called");
}
}
}

This should be the output from this test app:

ThreadState at start of catch-block: Running
Main(): Thread.Abort called
ThreadState at end of catch-block: AbortRequested
ThreadProc(): finally-block executed

Note that the code at the end of the try block and after the finally block
is never executed. But, the code in the catch-blcok after the main thread
is signaled does execute even though the main thread calls Thread.Abort().
In fact, it demonstrates that the call to Abort has set the ThreadState to
AbortRequested.

Best Regards,
Dustin Campbell
Developer Express Inc.
Oct 12 '06 #3

Dustin Campbell wrote:
It looks like the catch-block will be executed just like a finally block
will. Here's a sample console application that you can use to test this behavior:

using System;
using System.Threading;

namespace ThreadTest
{
class Program
{
static ManualResetEvent resetEvent = new ManualResetEvent(false);

static void ThreadProc()
{
string text = null;
try
{
Console.WriteLine(text.ToString());

Console.WriteLine("ThreadProc(): Code at end of try");
}
catch (NullReferenceException)
{
Console.WriteLine("ThreadState at start of catch-block: {0}", Thread.CurrentThread.ThreadState);
resetEvent.Set();
Thread.Sleep(1000);
Console.WriteLine("ThreadState at end of catch-block: {0}", Thread.CurrentThread.ThreadState);
}
finally
{
Console.WriteLine("ThreadProc(): finally-block executed");
}

Console.WriteLine("ThreadProc(): Code after finally-block");
}
static void Main(string[] args)
{
Thread t = new Thread(ThreadProc);
t.Start();
resetEvent.WaitOne();
t.Abort();
Console.WriteLine("Main(): Thread.Abort called");
}
}
}

This should be the output from this test app:

ThreadState at start of catch-block: Running
Main(): Thread.Abort called
ThreadState at end of catch-block: AbortRequested
ThreadProc(): finally-block executed

Note that the code at the end of the try block and after the finally block
is never executed. But, the code in the catch-blcok after the main thread
is signaled does execute even though the main thread calls Thread.Abort().
In fact, it demonstrates that the call to Abort has set the ThreadState to
AbortRequested.

Best Regards,
Dustin Campbell
Developer Express Inc.
Hi Dustin,

I know the following are true according to the spec of .net:
1) if the ThreadAbortException happens in the try block, the remaining
of the try block should not run. But the finally block will run
regardless.
2) if the ThreadAbortException happens in the finally block, the
remaining of the finally block should run (in fact, .NET 1.1
implemented it incorrectly. It seems to be fixed in .NET 2.0)

The question is, if ThreadAbortException happens in the catch block,
should the remaining of the catch block run or not according to the
spec? Or in another word, does Microsoft implement the
ThreadAbortException handling correctly in .NET 2.0 when it occurs in
the catch block of the child thread?

Thanks,
Bill

Oct 13 '06 #4
I know the following are true according to the spec of .net:
1) if the ThreadAbortException happens in the try block, the remaining
of the try block should not run. But the finally block will run
regardless.
2) if the ThreadAbortException happens in the finally block, the
remaining of the finally block should run (in fact, .NET 1.1
implemented it incorrectly. It seems to be fixed in .NET 2.0)
The question is, if ThreadAbortException happens in the catch block,
should the remaining of the catch block run or not according to the
spec? Or in another word, does Microsoft implement the
ThreadAbortException handling correctly in .NET 2.0 when it occurs in
the catch block of the child thread?
Bill, if you read my response carefully and run the test app, you'll find
that the remainder of the catch-block does run when a ThreadAbortException
occurs. If it didn't, this line would not have been sent to the console:
"ThreadState at end of catch-block: AbortRequested".

Best Regards,
Dustin Campbell
Developer Express Inc.
Oct 13 '06 #5
"Dustin Campbell" <du*****@no-spam-pleasedevexpress.comwrote in message
news:c1**************************@news.microsoft.c om...
Bill, if you read my response carefully and run the test app, you'll find
that the remainder of the catch-block does run when a ThreadAbortException
occurs. If it didn't, this line would not have been sent to the console:
"ThreadState at end of catch-block: AbortRequested".
That answers the question of what *does* happen. It doesn't answer the
question of what *should* happen.

I think Bill was asking the latter. I have to admit, I find it
non-intuitive that a ThreadAbortException doesn't get thrown immediately,
even when in the middle of a catch block. After all, as far as I know any
other exception that occurs while within the catch block gets thrown when it
happens.

It's definitely good to know what does happen. But it's also interesting to
know what should happen, especially when that's different from what does
happen. :)

Pete
Oct 13 '06 #6
V2 of the CLR no longer induces asynchronous Aborts (that is one thread
aborts another) while performing backout (catch, fault, filter or finaly
blocks). Note however that a host may always decide to escalate a CLR thread
Abort to a rude thread Abort, so be carefull when you rely on this, an
asynchronous thread abort should only be considered safe when being part of
a domain unload.
Willy.

<fo*******@hotmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...
|
| Dustin Campbell wrote:
| It looks like the catch-block will be executed just like a finally block
| will. Here's a sample console application that you can use to test this
behavior:
| >
| using System;
| using System.Threading;
| >
| namespace ThreadTest
| {
| class Program
| {
| static ManualResetEvent resetEvent = new ManualResetEvent(false);
| >
| static void ThreadProc()
| {
| string text = null;
| try
| {
| Console.WriteLine(text.ToString());
| >
| Console.WriteLine("ThreadProc(): Code at end of try");
| }
| catch (NullReferenceException)
| {
| Console.WriteLine("ThreadState at start of catch-block: {0}",
Thread.CurrentThread.ThreadState);
| resetEvent.Set();
| Thread.Sleep(1000);
| Console.WriteLine("ThreadState at end of catch-block: {0}",
Thread.CurrentThread.ThreadState);
| }
| finally
| {
| Console.WriteLine("ThreadProc(): finally-block executed");
| }
| >
| Console.WriteLine("ThreadProc(): Code after finally-block");
| }
| static void Main(string[] args)
| {
| Thread t = new Thread(ThreadProc);
| t.Start();
| resetEvent.WaitOne();
| t.Abort();
| Console.WriteLine("Main(): Thread.Abort called");
| }
| }
| }
| >
| This should be the output from this test app:
| >
| ThreadState at start of catch-block: Running
| Main(): Thread.Abort called
| ThreadState at end of catch-block: AbortRequested
| ThreadProc(): finally-block executed
| >
| Note that the code at the end of the try block and after the finally
block
| is never executed. But, the code in the catch-blcok after the main
thread
| is signaled does execute even though the main thread calls
Thread.Abort().
| In fact, it demonstrates that the call to Abort has set the ThreadState
to
| AbortRequested.
| >
| Best Regards,
| Dustin Campbell
| Developer Express Inc.
|
| Hi Dustin,
|
| I know the following are true according to the spec of .net:
| 1) if the ThreadAbortException happens in the try block, the remaining
| of the try block should not run. But the finally block will run
| regardless.
| 2) if the ThreadAbortException happens in the finally block, the
| remaining of the finally block should run (in fact, .NET 1.1
| implemented it incorrectly. It seems to be fixed in .NET 2.0)
|
| The question is, if ThreadAbortException happens in the catch block,
| should the remaining of the catch block run or not according to the
| spec? Or in another word, does Microsoft implement the
| ThreadAbortException handling correctly in .NET 2.0 when it occurs in
| the catch block of the child thread?
|
| Thanks,
| Bill
|
Oct 14 '06 #7

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: Anushya | last post by:
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...
0
by: Mark Phillips | last post by:
Hello, I am having a problem in which a file can get stuck open when a thread that is attempting to write to it gets aborted (ThreadAbortedException occurs). The log file gets stuck open until...
6
by: Bonj | last post by:
Say if i have a function, void FuncStart() { try { FuncDoActions(); //<nextlineofcode> } catch(ThreadAbortException)
6
by: Mitch | last post by:
My background thread is being terminated when my application exixts. However, it does not receive a ThreadAbortException so I am unable to cleanly diconnect from a remote object (which makes the...
4
by: Vivek | last post by:
Hi, I have a question regarding ThreadAbortException. Why is the thread abort exception rethrown at the end of a catch clause? Why is ThreadAbortException's behavior designed to be this way? ...
3
by: Steve - DND | last post by:
I just implemented a page that performs a Response.Redirect(url, true). As such, I wrapped it in a try catch, and explicitly caught a ThreadAbortException. However, the thread abort exception was...
1
by: Eric | last post by:
I have the following situation: I was getting intermittent errors using Reponse.Redirct("url", true) and was trying to catch the ThreadAbortException, but it was not staying caught and was showing...
3
by: =?Utf-8?B?RXRoYW4gU3RyYXVzcw==?= | last post by:
Hi, I am running a web service which sometimes throws exceptions. I have a lot of error trapping within the web service, but I have missed the current problem. I am working on the current issue,...
5
by: dorrit.Riemenschneider | last post by:
I've developed a sharepint webpart (ASP.NET 2.0 application) with use of the CrystalReportViewer web control (CrystalDecisions.Web.CrystalReportViewer). All works fine except the export of the...
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
0
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
0
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
0
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.