try/catch bubbles up through routines -why?

[WISEMANOFNARNIA]

I have Routine1, which calls Routine 2. Both have a 'try Catch'
clause. Routine 1 looks like this:
Sub Routine1()
Try
Routine2()
Catch
do something
End Try
End Sub

I notice that an error in routine2 is caught in its catch block.
There is a Response.Redirect statement in that catch block, that is
supposed to go to a error page where the user can enter some info on
how the error occurred. But that 'redirect' does not get executed,
instead the routine returns to the 'catch' block of routine #1.
Is there a way around this error?
Thanks,
Marvin

 

[Anthony Jones]

I have Routine1, which calls Routine 2. Both have a 'try Catch'
clause. Routine 1 looks like this:
Sub Routine1()
Try
Routine2()
Catch
do something
End Try
End Sub

I notice that an error in routine2 is caught in its catch block.
There is a Response.Redirect statement in that catch block, that is
supposed to go to a error page where the user can enter some info on
how the error occurred. But that 'redirect' does not get executed,
instead the routine returns to the 'catch' block of routine #1.
Is there a way around this error?

Sounds like there is an error in the call to Response.Redirect or in the
code that follows it, perhaps a more realistic sample of code would help.

 

[Göran Andersson]

I have Routine1, which calls Routine 2. Both have a 'try Catch'
clause. Routine 1 looks like this:
Sub Routine1()
Try
Routine2()
Catch
do something
End Try
End Sub

I notice that an error in routine2 is caught in its catch block.
There is a Response.Redirect statement in that catch block, that is
supposed to go to a error page where the user can enter some info on
how the error occurred. But that 'redirect' does not get executed,
instead the routine returns to the 'catch' block of routine #1.
Is there a way around this error?
Thanks,
Marvin

That is because you are catching exceptions that you shouldn't. The
Redirect method uses a ThreadAbortException to exit out of the code, and
you are catching that exception.

You should only catch the specific exceptions that you handle, and leave
other exceptions alone.

Never use a catch without specifying an exception type. In framework 1
this could be used to catch unmanaged exceptions, but since framework 2
those are wrapped in a managed exception object so there is no longer
any use for a catch without an exception type.

 

[Gregory A. Beamer]

Reading this, I find myself yelling NOOOOOOOOOOOOOO!!!

First, when you are using try ... catch, only add this where you are
actually handling the errors. I know you think that is what you are doing
with your response.redirect, but, in reality, you are circumventing the
natural flow of ASP.NET.

A better way to handle uncaught errors is to specify an error page in the
web.config and then handle the errors there.

When you set up soemthing like this:

try
{
int i = 1/0;
}
catch (DivideByZeroException ex)
{
Response.Redirect("myerrorpage.aspx");
}

you end up doing two things:

1. You obliterate the exception, so you have no clue what actually bombed.
2. You are essentially throwing from a try ... catch, kind of like this

try
{
int i = 1/0;
}
catch (DivideByZeroException ex)
{
thorw(ex);
}

All you have really done here is burn some CPU cycles for nothing. you are
better to establish an error page and catch everything there. You can then
display a friendly error message for the user and everyone is happy.

Another option is to code the error handler in your global file and log it
there. It is part of the ASP.NET cycle.

Hopefully this makes sense.

 

[Gregory A. Beamer]

More likely, he is causing a ThreadAbort error in the catch, which is caught
by the calling routine, which fires the same error. Ouch!