Tuesday, March 13, 2012

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... :/

0 comments:

Post a Comment