too many Try/Catch blocks in code. Is there a better way?

[GiJeet]

Hello, I come from the VB6 world where we'd put a single ON ERROR GOTO
ErrHandler at the top of a method. Now whenever an error happened it
would drop into the ErrHandler code. In .Net it seems like you have
too many Try/Catch statements all throughout the code. I think this
is ugly error handling.

Is there a better way to handle exceptions in .Net 2.0 + then putting
all these Try/Catch blocks around code?

G

 

[Anthony Jones]

Hello, I come from the VB6 world where we'd put a single ON ERROR GOTO
ErrHandler at the top of a method. Now whenever an error happened it
would drop into the ErrHandler code. In .Net it seems like you have
too many Try/Catch statements all throughout the code. I think this
is ugly error handling.

Is there a better way to handle exceptions in .Net 2.0 + then putting
all these Try/Catch blocks around code?

Not quite sure why you would get loads of Try Catches

In VB6:-

Function DoSomething() As Long

On Error Goto An_Error

'Code here

The_Exit:

'Tidy up
Exit Function

An_Error:

'Handle error
'optionally
Resume The_Exit
'or re-raise error not handled
' Duplicated Tidy up code
Err.Raise num, source, description

End Function


In C#:-

int DoSomething()
{
try
{
//code here
}
catch(SpecialException e) //optional
{
//code to handle special exception
}
catch(Exception e) //(Exception e) can be deleted it e not used
{
//code to handle general exception
}
finally
{
//Tidy up; this always runs.
}
}

The point is there is no need for multiple Try/Catch blocks any more than
there is a need for multiple On Error Resume Handler lines in a VB6
procedure.

 

[Jeff Johnson]

Hello, I come from the VB6 world where we'd put a single ON ERROR GOTO
ErrHandler at the top of a method. Now whenever an error happened it
would drop into the ErrHandler code. In .Net it seems like you have
too many Try/Catch statements all throughout the code. I think this
is ugly error handling.

I, too, am a seasoned VB6 programmer, and I think that try/catch is far more
elegant than what VB did. What makes it look "ugly" to you is that error
handling in VB was basically a hack that you've gotten used to. It's time to
get used to something else.

Is there a better way to handle exceptions in .Net 2.0 + then putting
all these Try/Catch blocks around code?

No. That's the way. Get used to it. Seriously. Anything else would be
beating your head against a wall.

 

[Göran Andersson]

Hello, I come from the VB6 world where we'd put a single ON ERROR GOTO
ErrHandler at the top of a method. Now whenever an error happened it
would drop into the ErrHandler code. In .Net it seems like you have
too many Try/Catch statements all throughout the code. I think this
is ugly error handling.

Is there a better way to handle exceptions in .Net 2.0 + then putting
all these Try/Catch blocks around code?

G

You could use the same catch-anything approach as in VB6, and use a
try..catch around all the code in the method, but that is not a good way
of handing exceptions. Just as the error handing in VB6 isn't very good
either.

You should only catch exceptions where you anticipate them, and you
should specify the exception type(s) that the code could normally throw.
If you catch an exception in your code that you don't know how to
handle, there is no point in catching it at that level. You should catch
that at the application level instead.

Handling exceptions correctly is a bit of work, but that is one of the
things that gives stability to the application.

 

[sloan]

http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!234.entry


You should find the Krzysztof Cwalina article and bookmark it.

You should also (via Brad Abram advice) write alot more try/finally

try
{

}
// an intentional lack of a "catch" here
finally
{

}

blocks (like above), rather than try/catch/finally blocks.
Allowing the exception to bubble up is usually a good default....unless you
have a specific reason to not do so.

..............

 

[Jeff Johnson]

The advantage of try/catch is that different parts of your program can
have
different error handlers. If you want the equivalent of "ON ERROR GOTO,"
put a single try/catch block around Application.Run(...) in the main
program.
(Or around the whole of whatever routine you want to protect.)

To be fair, VB could do the same thing. You could have On Error GoTo
ErrorHandler1 and later in the same procedure On Error GoTo ErrorHandler2.
It's just that most people didn't create multiple error handlers; they just
wrote one big one with a Select Case statement to examine the error number.
The real problem is that the error blocks weren't "directly connected" to
the statements that might fail; you had to jump into (goto) the error block
and then jump (resume) back.

 

[Anthony Jones]

To be fair, VB could do the same thing. You could have On Error GoTo
ErrorHandler1 and later in the same procedure On Error GoTo ErrorHandler2.
It's just that most people didn't create multiple error handlers; they
just wrote one big one with a Select Case statement to examine the error
number. The real problem is that the error blocks weren't "directly
connected" to the statements that might fail; you had to jump into (goto)
the error block and then jump (resume) back.

In most of those case though it would be clear that an extract function
refactor would be needed. As soon as you needed more than one On Error Goto
in a procedure it should immediately trigger that refactor.

 

[DaveL]

In many Cases
there is a Top Method calling the lower classes and methods

if you get a non recoverable error
1. What are you gonna do....nothing crash , log it etc

if you had a App Error Block (try/catch) at top of ur application
let it throw up to that

there are lots of specific places i will use try catch because i need to
catch the error where it took place
but many times , does not really matter if it just throws all the way up to
the top
log it, or do what you do with it

 

[Anthony Jones]

http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!234.entry


You should find the Krzysztof Cwalina article and bookmark it.

You should also (via Brad Abram advice) write alot more try/finally

try
{

}
// an intentional lack of a "catch" here
finally
{

}

blocks (like above), rather than try/catch/finally blocks.
Allowing the exception to bubble up is usually a good default....unless
you have a specific reason to not do so.

In many of such cases though the task to be performed in the finally is one
or more Dispose calls. In which case C#'s using() { } construct is better.

 

[sloan]

//

In many of such cases though the task to be performed in the finally is
one or more Dispose calls. In which case C#'s using() { } construct is
better.
//

I second that!

.........