468,780 Members | 2,349 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,780 developers. It's quick & easy.

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

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
Oct 28 '08 #1
9 2568
"GiJeet" <gi****@yahoo.comwrote in message
news:fe**********************************@p59g2000 hsd.googlegroups.com...
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.
--
Anthony Jones - MVP ASP/ASP.NET

Oct 28 '08 #2
"GiJeet" <gi****@yahoo.comwrote in message
news:fe**********************************@p59g2000 hsd.googlegroups.com...
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.
Oct 28 '08 #3
GiJeet wrote:
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.

--
Göran Andersson
_____
http://www.guffa.com
Oct 28 '08 #4
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.

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


"GiJeet" <gi****@yahoo.comwrote in message
news:fe**********************************@p59g2000 hsd.googlegroups.com...
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

Oct 28 '08 #5
"MC" <fo**************@www.ai.uga.edu.slash.mcwrote in message
news:ez*************@TK2MSFTNGP03.phx.gbl...
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.
Oct 28 '08 #6
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

"GiJeet" <gi****@yahoo.comwrote in message
news:fe**********************************@p59g2000 hsd.googlegroups.com...
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

Oct 28 '08 #7
"Jeff Johnson" <i.***@enough.spamwrote in message
news:eN**************@TK2MSFTNGP06.phx.gbl...
"MC" <fo**************@www.ai.uga.edu.slash.mcwrote in message
news:ez*************@TK2MSFTNGP03.phx.gbl...
>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.
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.

--
Anthony Jones - MVP ASP/ASP.NET

Oct 28 '08 #8
"sloan" <sl***@ipass.netwrote in message
news:Oy**************@TK2MSFTNGP02.phx.gbl...
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.
--
Anthony Jones - MVP ASP/ASP.NET

Oct 28 '08 #9
//
>
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!

.........

"Anthony Jones" <An***********@yadayadayada.comwrote in message
news:u3**************@TK2MSFTNGP05.phx.gbl...
"sloan" <sl***@ipass.netwrote in message
news:Oy**************@TK2MSFTNGP02.phx.gbl...
>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.
--
Anthony Jones - MVP ASP/ASP.NET

Oct 28 '08 #10

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by Erik Cruz | last post: by
11 posts views Thread by kaeli | last post: by
11 posts views Thread by Pohihihi | last post: by
22 posts views Thread by STom | last post: by
32 posts views Thread by cj | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
2 posts views Thread by Marin | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.