Help with System.Threading.ThreadAbortException

[markknowsley]

This is going to be Exception Handling 101 so apologies; I've used the Try - Catch - Finally in C# to catch any errors in my code.

I've set the program to email me when an error occurs; the statement is:

catch (Exception E)
{
string stringError = E.ToString();
SendErrorMail(variables);
Server.Transfer("Error.aspx");
}

Which is working. But I get emailed about this error:

System.Threading.ThreadAbortException: Thread was being aborted.
at System.Threading.Thread.AbortInternal()
at System.Threading.Thread.Abort(Object stateInfo)
at System.Web.HttpResponse.End()
at System.Web.HttpResponse.Redirect(String url, Boolean endResponse)
at System.Web.HttpResponse.Redirect(String url)

but it's not really an error - the code keeps going and (provided that nothing else has gone wrong) concludes successfully.

Is there something that I need to do about this thread exception? Will it cause problems?

 

[chiph]

What was your code doing at the time it threw?

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[Guru7777]

We do this in our catch block

if(ex is System.Threading.ThreadAbortException)
{}
else
{RecordError(ex);}

Hope that is helpful.


----------------------------------------

TWljcm8kb2Z0J3MgIzEgRmFuIQ==

 

[chiph]

Err, not particularly.


What is your code doing to cause this exception to be thrown? What does your stack trace say?

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[Guru7777]

My point was that this exception typically doesn't have a thing to do with what you are doing. From MSDN

When a call is made to the Abort method to destroy a thread, the common language runtime throws a ThreadAbortException. ThreadAbortException is a special exception that can be caught, but it will automatically be raised again at the end of the catch block. When this exception is raised, the runtime executes all the finally blocks before killing the thread.

Catching it doesn't matter because it is raised again at the end of the catch. Unless you need to handle it specifically to do something (which Mark didn't seem to need, since he indicated that all concluded nicely), catching it doesn't serve too much of a purpose.

In my code, the stack trace is as follows

at System.Threading.Thread.AbortInternal()
at System.Threading.Thread.Abort(Object stateInfo)
at System.Web.HttpResponse.End()
at System.Web.HttpResponse.Redirect(String url, Boolean endResponse)
at System.Web.HttpResponse.Redirect(String url)
at Login.btnLogin_Click(Object sender, EventArgs e) in <filenameremoved>

The exception is thrown in after success in this case. I merely offered that option to him, especially if he discovered that he had the same situation as we did.

----------------------------------------

TWljcm8kb2Z0J3MgIzEgRmFuIQ==

 

[markknowsley]

The code is inserting several values into a database. The exception was picking up an error where the value of one string was larger than the size of the database field, but I have fixed that now.

My exception block has a Server.Transfer(errorpage.aspx) and when I step through the code the compiler looks at this line but ignores it and executes successfully.

From what Guru777 says, I can ignore it because all concluded nicely. But why would I need to handle this error if it's not stopping my program from working?

 

[stevexff]

The exception was picking up an error where the value of one string was larger than the size of the database field, but I have fixed that now.

if your code was working properly, you wouldn't have needed to fix it. If you had handled it as suggested, you wouldn't have found this error.

Sidebar on field truncation: I once worked at a site where one of the customers (Mr. Farthing) wrote in to complain that his surname had been truncated to four characters in the salutation of a form letter they'd sent him...

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]

 

[markknowsley]

Don't understand what you mean by
"if your code was working properly, you wouldn't have needed to fix it. If you had handled it as suggested, you wouldn't have found this error"

Are you saying that I shouldn't have increased the size of the database field, even though people attempting to insert a statement bigger than the maximum size were getting an error message from my form.

Does the exception handler log into sql server and change the database size for me?

Don't think so.

 

[chiph]

My guess is that the unhandled SQLException caused the ASP worker process to abort.

Add an unhandled exception handler:

// Set the unhandled exception handler
AppDomain currentDomain = AppDomain.CurrentDomain;
currentDomain.UnhandledException += new UnhandledExceptionEventHandler(UnhandledErrorController.UnhandledExceptionHandler);

where [tt]UnhandledErrorController.UnhandledExceptionHandler[/tt] is a static method that logs the error for later work.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first