Is a multiple try-catch-throw useful?

[Arjen]

Hi,

I'm doing this:
try {

try {

}
catch(Exception ex){
throw;
}

}
catch(Exception ex){
throw;
}

Is a nestled try-catch-throw useful? Or is one enough?

Thanks!

[Johann Blake]

Arjen,

Why would it not be useful? Even within the "finally" clause, you can
use a try...catch statement. I do it quite often. Use try...catch
anywhere you want. The point about using it is to simply catch
exceptions, either known or unknown and exceptions can occur ANYWHERE
in your application, even in places where there is no executable code
(that is, code that you didn't necessarily write).

Best Regards
Johann Blake

[Brian Delahunty]

The code example you have given isn't the most useful in my opinion. Haveing
nested try-catches is useful is you are actually going to do something with
the exception in the first catch (e.g. some cleanup - but this should really
be done in a finally)... in your example below your first catch statement is
doing nothing and the only result is that it is slowing your application down
in situations where an exception is thrown.

In your example you are doing nothing at all with the exceptions in either
case so I'd question why they are being caught at all... other then to make
it appear that a different method threw it.

If you have shown something like the following then it's perfectly fine and
needed in my opinion:

try {

try {

}
catch(...){
// Only catch if you're going to do something with it
}
finally{
// do some cleanup here
}

}
catch(Exception ex){

// Do something with the exception and then throw it up the stack if you
want.
throw;
}
"Arjen" wrote:

Hi,

I'm doing this:
try {

try {

}
catch(Exception ex){
throw;
}

}
catch(Exception ex){
throw;
}

Is a nestled try-catch-throw useful? Or is one enough?

Thanks!

[Brian Delahunty]

The code example you have given isn't the most useful in my opinion. Haveing
nested try-catches is useful if you are actually going to do something with
the exception in the first catch (e.g. some cleanup - but this should really
be done in a finally)... in your example below your first catch statement is
doing nothing and the only result is that it is slowing your application down
in situations where an exception is thrown.

Actually, in your example you are doing nothing at all with the exceptions
in either catch so I'd question why they are being caught at all... other
then to make it appear that a different method threw it.

If you have shown something like the following then it's perfectly fine and
needed in my opinion:

try {

try {

}
catch(...){
// Only catch if you're going to do something with it
}
finally{
// do some cleanup here
}

}
catch(Exception ex){

// Do something with the exception and then throw it up the stack if you
want.
throw;
}
"Arjen" wrote:

Hi,

I'm doing this:
try {

try {

}
catch(Exception ex){
throw;
}

}
catch(Exception ex){
throw;
}

Is a nestled try-catch-throw useful? Or is one enough?

Thanks!

[Arjen]

Maybe you can help me with telling me the best thing to do.

I have some code blocks (lines of code) inside a method. These blocks are
using the using-statement for data access. It will look like this:

// Start method
// Code block
// Nested codeblock
// Code block
// End method (haves return value)

This method is called from an asp.net code-behind method. If there is an
error the user must see the error.aspx file.

Where do I need to add the try-catch-statements?
For each codeblock? Or only one in the code behind-file?

Thanks!
Arjen


"Brian Delahunty" <Br************@discussions.microsoft.com> schreef in
bericht news:81**********************************@microsof t.com...

The code example you have given isn't the most useful in my opinion.
Haveing
nested try-catches is useful is you are actually going to do something
with
the exception in the first catch (e.g. some cleanup - but this should
really
be done in a finally)... in your example below your first catch statement
is
doing nothing and the only result is that it is slowing your application
down
in situations where an exception is thrown.

In your example you are doing nothing at all with the exceptions in either
case so I'd question why they are being caught at all... other then to
make
it appear that a different method threw it.

If you have shown something like the following then it's perfectly fine
and
needed in my opinion:

try {

try {

}
catch(...){
// Only catch if you're going to do something with it
}
finally{
// do some cleanup here
}

}
catch(Exception ex){

// Do something with the exception and then throw it up the stack if you
want.
throw;
}
"Arjen" wrote:

Hi,

I'm doing this:
try {

try {

}
catch(Exception ex){
throw;
}

}
catch(Exception ex){
throw;
}

Is a nestled try-catch-throw useful? Or is one enough?

Thanks!

[Arjen]

I don't know if a try-catch is necesarry for each codeblock.

Take for example this situation.
// Layer 1
// Layer 2
// Layer 3

Layer 1 calls a method inside layer 2.
The method in layer 1 that calls the method looks like this:
...try { layer2.method() } catch {...}..

Do I need to add try-catch statement inside the other layers?

Thanks!
Arjen


"Johann Blake" <jo*********@yahoo.com> schreef in bericht
news:11**********************@g47g2000cwa.googlegr oups.com...

Arjen,

Why would it not be useful? Even within the "finally" clause, you can
use a try...catch statement. I do it quite often. Use try...catch
anywhere you want. The point about using it is to simply catch
exceptions, either known or unknown and exceptions can occur ANYWHERE
in your application, even in places where there is no executable code
(that is, code that you didn't necessarily write).

Best Regards
Johann Blake

[Brian Delahunty]

Well if the use has to see the error.aspx page regardless of where the
exception occurred in the method and you are not doing anything else with the
exception (e.g. attempting to recover, logging it, etc) then just wrap the
"dangerous" (i.e. exception throwing part) of the method in a try-catch and
redirect to the error.aspx file in the catch.

Alternatively you could just set the ErrorPage property of the page to point
to error.aspx and not handle the exception at all. This way ASP.NET itself
will redirect to the page for you on unhandled exceptions.

hope this helps.

Brian Delahunty
Ireland

http://briandela.com/blog
"Arjen" wrote:

Maybe you can help me with telling me the best thing to do.

I have some code blocks (lines of code) inside a method. These blocks are
using the using-statement for data access. It will look like this:

// Start method
// Code block
// Nested codeblock
// Code block
// End method (haves return value)

This method is called from an asp.net code-behind method. If there is an
error the user must see the error.aspx file.

Where do I need to add the try-catch-statements?
For each codeblock? Or only one in the code behind-file?

Thanks!
Arjen


"Brian Delahunty" <Br************@discussions.microsoft.com> schreef in
bericht news:81**********************************@microsof t.com...

The code example you have given isn't the most useful in my opinion.
Haveing
nested try-catches is useful is you are actually going to do something
with
the exception in the first catch (e.g. some cleanup - but this should
really
be done in a finally)... in your example below your first catch statement
is
doing nothing and the only result is that it is slowing your application
down
in situations where an exception is thrown.

In your example you are doing nothing at all with the exceptions in either
case so I'd question why they are being caught at all... other then to
make
it appear that a different method threw it.

If you have shown something like the following then it's perfectly fine
and
needed in my opinion:

try {

try {

}
catch(...){
// Only catch if you're going to do something with it
}
finally{
// do some cleanup here
}

}
catch(Exception ex){

// Do something with the exception and then throw it up the stack if you
want.
throw;
}
"Arjen" wrote:

Hi,

I'm doing this:
try {

try {

}
catch(Exception ex){
throw;
}

}
catch(Exception ex){
throw;
}

Is a nestled try-catch-throw useful? Or is one enough?

Thanks!

[Arjen]

Okay, thanks.

I use the enterprise library for exception handling and logging.

After the exception I want to redirect the use to the error.aspx file.

Thanks!
"Brian Delahunty" <Br************@discussions.microsoft.com> schreef in
bericht news:20**********************************@microsof t.com...

Well if the use has to see the error.aspx page regardless of where the
exception occurred in the method and you are not doing anything else with
the
exception (e.g. attempting to recover, logging it, etc) then just wrap the
"dangerous" (i.e. exception throwing part) of the method in a try-catch
and
redirect to the error.aspx file in the catch.

Alternatively you could just set the ErrorPage property of the page to
point
to error.aspx and not handle the exception at all. This way ASP.NET itself
will redirect to the page for you on unhandled exceptions.

hope this helps.

Brian Delahunty
Ireland

http://briandela.com/blog
"Arjen" wrote:

Maybe you can help me with telling me the best thing to do.

I have some code blocks (lines of code) inside a method. These blocks are
using the using-statement for data access. It will look like this:

// Start method
// Code block
// Nested codeblock
// Code block
// End method (haves return value)

This method is called from an asp.net code-behind method. If there is an
error the user must see the error.aspx file.

Where do I need to add the try-catch-statements?
For each codeblock? Or only one in the code behind-file?

Thanks!
Arjen


"Brian Delahunty" <Br************@discussions.microsoft.com> schreef in
bericht news:81**********************************@microsof t.com...

> The code example you have given isn't the most useful in my opinion.
> Haveing
> nested try-catches is useful is you are actually going to do something
> with
> the exception in the first catch (e.g. some cleanup - but this should
> really
> be done in a finally)... in your example below your first catch
> statement
> is
> doing nothing and the only result is that it is slowing your
> application
> down
> in situations where an exception is thrown.
>
> In your example you are doing nothing at all with the exceptions in
> either
> case so I'd question why they are being caught at all... other then to
> make
> it appear that a different method threw it.
>
> If you have shown something like the following then it's perfectly fine
> and
> needed in my opinion:
>
> try {
>
> try {
>
> }
> catch(...){
> // Only catch if you're going to do something with it
> }
> finally{
> // do some cleanup here
> }
>
> }
> catch(Exception ex){
>
> // Do something with the exception and then throw it up the stack if
> you
> want.
> throw;
> }
>
>
> "Arjen" wrote:
>
>> Hi,
>>
>> I'm doing this:
>> try {
>>
>> try {
>>
>> }
>> catch(Exception ex){
>> throw;
>> }
>>
>> }
>> catch(Exception ex){
>> throw;
>> }
>>
>> Is a nestled try-catch-throw useful? Or is one enough?
>>
>> Thanks!
>>
>>
>>