"on error goto" or "try catch"

[DraguVaso]

Hi,

As a former VB-programmer I'm used to the "on error goto"-errorhandling. I
see that in actually all the VB.NET-samples I can fin people use the "Try -
catch"-errorhandling.

Which of the two is the best? Are there good reasons to use the Try-Catch?
Will the "on error goto" disapear in the future? Are there any logical
reasons to use trey-catch? Is it 'better' programming? etc etc

I'm jsut more comfortable with the "on error goto", mostly because I'm used
to it I guess. Any help or reflectiosn regarding this subject would be nice!

Thanks in advance!

 

[Cor]

Hi Dragu,

If you are used to the possibilties from the

Try
Catch (multiples
End Try
Finally

And the nesting posibilities from that, you would not believe you could do
it with the "on error goto"

I hope this gives an idea?

Cor

 

[Valeria]

Hi,
I was a VB-programmer to and I was used to on error but now Try .. catch is
better.
With this statement you can catch all different types of exceptions and
perform a specific action for each one.
I hope this will be usefull for you
Regards
Valeria

 

[Herfried K. Wagner [MVP]]

I was a VB-programmer to and I was used to on error but now Try .. catch is
better.

But: _Why_ exactly is it better? It's IMO better in some cases because it
leaves code more compact, but sometimes, for example when impementing a
large algorithm, it's very annoying because it will prevent the reader
from seeing the point of the code.

Just a thought.

 

[Cor]

Hi Herfried,

That discussion was done before you was born

If you have problems with that, start studing Pascal, that was special made
for it.



Cor

 

[Herfried K. Wagner [MVP]]

That discussion was done before you was born

If you have problems with that, start studing Pascal, that was special made
for it.

LOOOOOOOL.

 

[Valeria]

I think is better only because in this way I can simply specify different
actions for each exception if you want and I never loved on error
statement...
a personal opinion maybe!
Valeria

 

[Herfried K. Wagner [MVP]]

I think is better only because in this way I can simply specify different
actions for each exception if you want and I never loved on error
statement...
a personal opinion maybe!

\\\
Select Case Err.Number
Case err1, err2
...
Case err3
...
...
End Select
///

IMO, unstructured error handling is a nice feature in some cases, but
generally, structured error handling should be preferred.

 

[DraguVaso]

Ok!! Thanks everybody!
I got on GotDotNet two nice related articles about it:
http://msdn.microsoft.com/library/en-us/dv_vstechart/html/vbnet_errorhandlin
g.asp

http://msdn.microsoft.com/library/en-us/dv_vstechart/html/vbtchExceptionsErr
orsInVisualBasicNET.asp

I think is better only because in this way I can simply specify different
actions for each exception if you want and I never loved on error
statement...
a personal opinion maybe!
Valeria

catch

 

[Cor]

Brrrrrrrrrrrrrrrrrrrrrrrr

What is here the difference with a standarized try catch end try finally
solution?

Answer, I have to check the list with errornumbers, and need HKW to give me
a link for that.

\\\
Select Case Err.Number
Case err1, err2
...
Case err3
...
...
End Select
///

Cor

 

[Herfried K. Wagner [MVP]]

Brrrrrrrrrrrrrrrrrrrrrrrr
;-)

What is here the difference with a standarized try catch end try finally
solution?

There is no big difference.

Answer, I have to check the list with errornumbers, and need HKW to give me
a link for that.

The sample above is VB6 code.

;->

 

[Jay B. Harlow [MVP - Outlook]]

Herfried,

for example when impementing a large algorithm,

Although I may implement a large algorithm, I tend to implement it with
smaller routines, which helps avoid this problem, or at least it spreads the
problem out.

Of course one can have routines that are too small...

Just a thought
Jay

 

[Jay B. Harlow [MVP - Outlook]]

DraguVaso,
A year and a half or two years ago there were a couple big discussions on
this subject, I'm not sure how easy it would be to find those threads in
this newsgroup at http://groups.google.com...

I generally only use Try/Catch blocks where I have to use a try/catch block,
generally when I am managing a resource, for example a SqlConnection that I
need to be certain I close when I exit a routine. Or I cannot use a method
to avoid the exception (HashTable.Contains to see if the key exists before
using HashTable.Item to retrieve the item).

In .NET there is less of a need to include error handlers in every routine,
for example in Windows Forms applications you can set a global exception
handler that will effectively add a error handler to each of your event
handlers under the covers, this global exception handler can log the error
and allow you app to continue in a predictable manner.

Depending on the type of application you are creating, .NET has three
different global exception handlers.

For Windows Forms look at:
System.Windows.Forms.Application.ThreadException event
Use AddHandler in your Sub Main before you call Application.Run.

For ASP.NET look at:
System.Web.HttpApplication.Error event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomain.UnhandledException event
Use AddHandler in your Sub Main.

Hope this helps
Jay

 

[One Handed Man [ OHM ]]

I say to hell with error handling, throw ( no pun intended ) caution to the
wind and simply put the following statement before any block of code.

On Error Resume Next ' Syntax for ( who gives a $h*t )
ROTFLMAO

OHM

Brrrrrrrrrrrrrrrrrrrrrrrr

What is here the difference with a standarized try catch end try
finally solution?

Answer, I have to check the list with errornumbers, and need HKW to
give me a link for that.


Cor

Best Regards - OHMBest Regards - OHM (e-mail address removed)

 

[Cor]

Hi OHM

Is that the same as?

sub blabla
try
do your statements
catch
end try
end sub

Cor

 

[One Handed Man [ OHM ]]

Almost, just that in scenario Resume Next, you just carry one regardless.

Cheers - OHM

Hi OHM

Is that the same as?

sub blabla
try
do your statements
catch
end try
end sub

Cor

Best Regards - OHMBest Regards - OHM (e-mail address removed)

 

[Cor]

Hi OHM

With this also or I see something totaly wrong

 

[Herfried K. Wagner [MVP]]

Brrrrrrrrrrrrrrrrrrrrrrrr

What is here the difference with a standarized try catch end try finally
solution?

Why is 'Try...Catch' standardized and 'On Error...' not standardized?

 

[Herfried K. Wagner [MVP]]

With this also or I see something totaly wrong

Don't you have the help files installed?!

 

[Cor]

Herfried,

Why is 'Try...Catch' standardized and 'On Error...' not standardized?

That one I should not have used, I just made a message in the thread from
Ivan Weiss that in my opinion it looks if people want to make from VB.net
something as C.

I did not write it but with those sentence you know I mean things as
dim a as string = (Cint(Dbl(8/1)*2)).tostring

But one of the things I alway deny in every language is a goto and an alter.
(Altering is changing pointers, the first commando like that was branch
conditional register)

The "case select" was in past also a kind of goto so I did not want that
either, although the newones are no problem anymore for me.

I never understood how to handle that Onerror goto from VB while giving the
code also a good description value.

Cor