"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!

[Herfried K. Wagner [MVP]]

* "Cor" <no*@non.com> scripsit:

Brrrrrrrrrrrrrr rrrrrrrrrr
;-)
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.

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

The sample above is VB6 code.

;->

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[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

"Herfried K. Wagner [MVP]" <hi************ ***@gmx.at> wrote in message
news:bq******** *****@ID-208219.news.uni-berlin.de... * "Valeria" <va***@tiscali. it> scripsit:

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.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[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.Cont ains 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.Applicati on.ThreadExcept ion event
Use AddHandler in your Sub Main before you call Application.Run .

For ASP.NET look at:
System.Web.Http Application.Err or event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomai n.UnhandledExce ption event
Use AddHandler in your Sub Main.

Hope this helps
Jay
"DraguVaso" <pi**********@h otmail.com> wrote in message
news:3f******** **************@ reader0.news.sk ynet.be...

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!

[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


Cor wrote:

Brrrrrrrrrrrrrr rrrrrrrrrr

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

Best Regards - OHMBest Regards - OHM On**********@BT Internet.Com

[Cor]

Hi OHM

Is that the same as?

sub blabla
try
do your statements
catch
end try
end sub

Cor

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

OHM


Cor wrote:

Brrrrrrrrrrrrrr rrrrrrrrrr

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

Best Regards - OHMBest Regards - OHM On**********@BT Internet.Com

[One Handed Man [ OHM ]]

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

Cheers - OHM

Cor wrote:

Hi OHM

Is that the same as?

sub blabla
try
do your statements
catch
end try
end sub

Cor

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

OHM


Cor wrote:

Brrrrrrrrrrrrrr rrrrrrrrrr

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

Best Regards - OHMBest Regards - OHM On**********@BT Internet.Com

Best Regards - OHMBest Regards - OHM On**********@BT Internet.Com

[Cor]

Hi OHM

With this also or I see something totaly wrong

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

sub blabla
try
do your statements
catch
end try
end sub

[Herfried K. Wagner [MVP]]

* "Cor" <no*@non.com> scripsit:

Brrrrrrrrrrrrrr rrrrrrrrrr

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]
<http://www.mvps.org/dotnet>

[Herfried K. Wagner [MVP]]

* "Cor" <no*@non.com> scripsit:

With this also or I see something totaly wrong

Don't you have the help files installed?!

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[Cor]

Herfried,

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

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