Help with Response.Redirect(URL,True) behavior

[Guest]

We are getting a behavior on a Response.Redirect("SomeUrl", True) that I'm
hoping someone can explain. This all refers to the code snip at the end. By
the way, this is all VB ASP.NET v1.0 code.

So we have the Page_Load event of an ASPX page fire which in the snip you
see calls "SomeMethod". Also you see in Page_Load two Catch statements. The
first is "SpecialException". We created our own extended exception (inherits
from ApplicationException) class to handle certain properties and
functionality not in any standard .NET Exception. The second Catch in
Page_Load traps any other possible exceptions, creates a new
"SpecialException", sets certain properties based on the exception that was
raised and calls "DisplayMethod" to perform needed functions.

Anyway, "SomeMethod" gets called and in there let's say a DivideByZero
exception happens for the sake of an example. In "SomeMethod", the error is
trapped at "Catch ex As Exception". A new SpecialException is created,
populated and then passed to method "DisplayError".

In "DisplayError" you see we handle logging, some other error info massaging
and then finally attempt to do a redirect to our error display page.
Originally we had False in the Redirect method, but since execution would
continue, we'd have other methods finish getting called (some of which made
DB calls), etc. Not wanting to incur all that extra and unnecessary
method/DB calling, we decided to have the current page processing
stop...hence the True for the end response parm. Knowing that raises its own
error, we catch for the ThreadAbortException and "eat" that error...or so we
thought.

It turns out that even though we explicitly trap for that
TreadAbortException error, it still bubbles up the stack. The DivideByZero
error popped in "SomeMethod" and was handled with "Catch ex As Exception"
which then did the "Call DisplayError(New
SpecialException(ex.Message,ex.StackTrace,etc))". In DisplayError we handled
the error, did the Redirect and trapped the ThreadAbortException. From
DisplayError, execution continued back at the "Catch ex As Exception" handler
in "SomeMethod" and then I expected execution to exit from Page_Load
immediately and pick back up at our error display page based on the
Response.Redirect. Well instead, execution picked back up in Page_Load at
its "Catch ex As Exception" error catch and then itself tries to "Call
DisplayError(New SpecialException(ex.Message,ex.StackTrace,etc))".
Furthermore, the "ex" error variable set up there says it is handling the
ThreadAbortException that I thought we already handled in DisplayError.
Fortunately in DisplayError we do some Session checking and see we've already
handled/logged an error so we don't try to do it again and also do not try to
do another Response.Redirect. Execution does finally make it to our error
display page, but I am trying to understand why the "Catch ex As Exception"
in Page_Load is catching the ThreadAbortException that was thrown, and
supposedly already trapped, in DisplayError.

Here's the pseudo-snip:
===============
Public Sub Page_Load()
Try
...
Call SomeMethod
...
Catch sx As SpecialException
Call DisplayError(sx) method to log and show user message
Catch ex As Exception
Call DisplayError(New SpecialException(ex.Message,ex.StackTrace,etc))
End Try
End Sub
Public Sub SomeMethod
Try
...
***Let's just say DivideByZero pops here***
Some Processing
More Processing
...
Catch sx As SpecialException
Call DisplayError(sx) method to log and show user message
Catch ex As Exception
Call DisplayError(New SpecialException(ex.Message,ex.StackTrace,etc))
End Try
End Sub
Public Sub DisplayError(ByRef Exception As SpecialException)
Try
Handle Logging
Perform Other error-massaging
Try
Response.Redirect("OurCustomErrorDisplayPage.aspx", True)
Catch tae As System.Threading.ThreadAbortException
Eat the Redirect's abort exception here
End Try
Catch ex As Exception
Eat any other possible exception here
End Try
End Sub
============

Thanks in advance.

-Mike

 

[Guest]

Seems I just read the reason why this is happening in online docs for the
ThreadAbortException. Per the docs:
==================
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. Since the
thread can do an unbounded computation in the finally blocks, you must call
the Join method to guarantee that the thread has died. Join is a blocking
call that does not return until the thread actually stops executing.
==================

So it automatically gets raised again at the end of each catch block. Argh!
Any other suggestions for a "clean" way to handle this? Again we want to
avoid all that extra method/DB calling.

Thanks.

-Mike