Showing posts with label systemthreadingthreadabortexception. Show all posts
Showing posts with label systemthreadingthreadabortexception. Show all posts

Tuesday, March 13, 2012

System.Threading.ThreadAbortException

Hi,

I'm running some code that posts from my application (ASP.Net) to a Payment Gateway. I get this error - [System.Threading.ThreadAbortException] = {Unable to evaluate expression because the code is optimized or a native frame is on top of the call stack.}. I guess this is because my I am transfering to another server and once this is done my code doesn't know what to do with itself.

Could someone explain what this error is precisely, and how I might avoid it.

Regards,

Quinton Smith

For any one wondering what I did to get this working as no one answered, I had to move my code transferring so that it was the last code running before transfer and not in any try/catch blocks.

Still don't quite understand the error description though.

Quinton


Not enough info to give an accurate answer, but if you're using Response.Redirect:

From Visual Studio Help:
Redirect calls End which always raises a ThreadAbortException exception upon completion.

NC...


youre the man! out of the first couple of posts yours is the only one that actually helped KUDOS!

Hi Programmers,

I am using asp.net 2.0 with c#.

" myReportDocument.ExportToHttpResponse(CrystalDecisions.Shared.ExportFormatType.PortableDocFormat, Response, false, rptName);"

As soon as compiler execute this statement i get error

" [System.Threading.ThreadAbortException] = {Unable to evaluate expression because the code is optimized or a native frame is on top of the call stack.} "

What will be the possible reasons for the error.

Sorry for the bad english.


I believe that this is because, Response.End is called internally in the ExportToHttpResponse method:

Try wrapping it in a try/catch block:

try
{
myReportDocument.ExportToHttpResponse(...);
}
catch (System.Threading.ThreadAbortException)
{
}

NC...


Thanks for reply,

I m already using try{} catch{} block

try

{

Some coding here

try
{

Response.TransmitFile("CodeGeneratedFiles/" + TemplateFileName);
Response.End();
}

catch (System.Threading.ThreadAbortException ex)
{
Log.WriteLog("Report Viewer", "Set The Datasource", ex.Source, ex.Message);
}

Response.Addheader("Title","Some Name for Popup");

}

Catch(Exception ex)

{

}

But it does not execute "Response.Addheader("title","Some Name for Popup");" after catch block it directly jumps to outer catch block.

Is there anyway to kill the exception..

Is there no other way to solve this error.[System.Threading.ThreadAbortException] = {Unable to evaluate expression because the code is optimized or a native frame is on top of the call stack.}

Hope to hear u soon.


No as I think there is a bug in ExportToHttpResponse. You might try Googling ExportToHttpResponse and System.Threading.ThreadAbortException. I found some work-a-rounds there.

NC...

System.Threading.ThreadAbortException and Response.Redirect

I have an ASP.net 2.0 app on a W2K3 box. I am using Response.Redirect inside page_load. After reading a bunch of posts, I've tried setting the second arg to false, but still get the error. I've also tried moving the redirect outside the try block. No love. I catch and ignore the error, but the redirect doesn't redirect to the new url.

All worked fine until this started happening out of the blue.

Thanks.

I assume you meant to post your code... but you forgot. Can you post your problem code please?


oops. Sorry.

If Request.QueryString("testnum") Is Nothing Then
Response.Redirect("http://localhost:10607/WWW/testing.aspx?testnum=1.11-.01-C1-T1&ucid=0")

End if


Have you tried using a relative URL, instead of an absolute URL?

The thing is, the built in web server in Visual Studio (Cassini) uses dynamic port assignment. Therefore, there is no guarantee (in fact no likelihood at all) that the port used will be the same every time.

Try a URL of"~/testing.aspx?testnum=1.11-.01-C1-T1&ucid=0"

System.Threading.ThreadAbortException and Response.Redirect

I have implemented a log-system for exceptions in an ASP.NET
application using the Application_Error event in Global.asax.
ThreadAbortExceptions gets thrown everytime Response.Redirect is being
used with the second parameter set to true which, according to
Microsoft, is by design...

How do I get around this ? I would hate to have the log filled with
this exception on high-traffic sites. Setting the second parameter to
false is not an option.

I have tried with a try-catch block around the Response.Redirect call,
didnt help, the exception still gets "recorded".A couple options...

a - Don't set the 2nd parameter to true

b - Before logging the exception, check it's type and don't log
ThreadAbortExceptions

Karl

--
http://www.openmymind.net/
http://www.fuelindustries.com/
"Henrik Stidsen" <henrikstidsen@.gmail.comwrote in message
news:1157013808.231659.114100@.e3g2000cwe.googlegro ups.com...
I have implemented a log-system for exceptions in an ASP.NET
application using the Application_Error event in Global.asax.
ThreadAbortExceptions gets thrown everytime Response.Redirect is being
used with the second parameter set to true which, according to
Microsoft, is by design...

How do I get around this ? I would hate to have the log filled with
this exception on high-traffic sites. Setting the second parameter to
false is not an option.

I have tried with a try-catch block around the Response.Redirect call,
didnt help, the exception still gets "recorded".
Karl Seguin [MVP] skrev:

Quote:

Originally Posted by

A couple options...
a - Don't set the 2nd parameter to true


It would certainly be the easy way - but sometimes the world is not
that easy :(

Quote:

Originally Posted by

b - Before logging the exception, check it's type and don't log
ThreadAbortExceptions


Wouldn't I risk to throw out exceptions that I want to log or is
Response.Redirect the only (built-in) function that throws this
Exception ?
No, it isn't the only function, so yes, you'd risk throwing away meaningful
information.

Karl

--
http://www.openmymind.net/
http://www.fuelindustries.com/
"Henrik Stidsen" <henrikstidsen@.gmail.comwrote in message
news:1157030635.410199.270240@.i42g2000cwa.googlegr oups.com...

Quote:

Originally Posted by

Karl Seguin [MVP] skrev:

Quote:

Originally Posted by

>A couple options...
>a - Don't set the 2nd parameter to true


>
It would certainly be the easy way - but sometimes the world is not
that easy :(
>

Quote:

Originally Posted by

>b - Before logging the exception, check it's type and don't log
>ThreadAbortExceptions


>
Wouldn't I risk to throw out exceptions that I want to log or is
Response.Redirect the only (built-in) function that throws this
Exception ?
>


This will give more clarity: http://support.microsoft.com/kb/312629/EN-US/
"Henrik Stidsen" <henrikstidsen@.gmail.comwrote in message
news:1157013808.231659.114100@.e3g2000cwe.googlegro ups.com...
I have implemented a log-system for exceptions in an ASP.NET
application using the Application_Error event in Global.asax.
ThreadAbortExceptions gets thrown everytime Response.Redirect is being
used with the second parameter set to true which, according to
Microsoft, is by design...

How do I get around this ? I would hate to have the log filled with
this exception on high-traffic sites. Setting the second parameter to
false is not an option.

I have tried with a try-catch block around the Response.Redirect call,
didnt help, the exception still gets "recorded".
Siva M skrev:

Quote:

Originally Posted by

This will give more clarity: http://support.microsoft.com/kb/312629/EN-US/


I have read that - it seems the only way to avoid the exception is
this:
Response.Redirect(NewURL, False)
HttpContext.Current.ApplicationInstance.CompleteRe quest()

That seems like a bad workaround... :/