On Error Resume Next

[kimiraikkonen]

Hi,
I want to find out if there's difference between "On Error Resume
Next" error handler and leaving "catch" block empty in a try-catch-end
try block to ignore exceptions which i don't approve of course but
just needed to ask.

Thanks

[Herfried K. Wagner [MVP]]

"kimiraikkonen" <ki*************@gmail.comschrieb:

I want to find out if there's difference between "On Error Resume
Next" error handler and leaving "catch" block empty in a try-catch-end
try block to ignore exceptions which i don't approve of course but
just needed to ask.

'On Error Resume Next' will continue execution on the next statement after
the statement which raised the error/threw the exception whereas
'Try...Catch' will stop execution and jump directly into the 'Catch' block.

\\\
On Error Resume Next
<Statement 1>
<Statement 2 ' Statement throwing an exception.
<Statement 3>
On Error GoTo 0
///

In the code above <Statement 3will be executed, but it won't be executed
in the code sample below:

\\\
Try
<Statement 1>
<Statement 2 ' Statement throwing an exception.
<Statement 3>
Catch
End Try
///

To archieve similar behavior to 'On Error Resume Next' you'd have to put
each statement in a separate 'Try...Catch' block.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Michael D. Ober]

"kimiraikkonen" <ki*************@gmail.comwrote in message
news:3a**********************************@i3g2000h sf.googlegroups.com...

Hi,
I want to find out if there's difference between "On Error Resume
Next" error handler and leaving "catch" block empty in a try-catch-end
try block to ignore exceptions which i don't approve of course but
just needed to ask.

Thanks

On Error Resume Next
Statement 1
Statement 2
....

is the same as

Try
statement 1
catch
end try
try
statement 2
catch
end try
....

Mike.

[kimiraikkonen]

On Jan 21, 12:05*am, "Herfried K. Wagner [MVP]" <hirf-spam-me-
[e-mail]:

"kimiraikkonen" <[e-mail]:

I want to find out if there's difference between "On Error Resume
Next" error handler and leaving "catch" block empty in a try-catch-end
try block to ignore exceptions which i don't approve of course but
just needed to ask.

'On Error Resume Next' will continue execution on the next statement after
the statement which raised the error/threw the exception whereas
'Try...Catch' will stop execution and jump directly into the 'Catch' block..

\\\
On Error Resume Next
<Statement 1>
<Statement 2* *' Statement throwing an exception.
<Statement 3>
On Error GoTo 0
///

In the code above <Statement 3will be executed, but it won't be executed
in the code sample below:

\\\
Try
* * <Statement 1>
* * <Statement 2* *' Statement throwing an exception.
* * <Statement 3>
Catch
End Try
///

To archieve similar behavior to 'On Error Resume Next' you'd have to put
each statement in a separate 'Try...Catch' block.

--
*M S * Herfried K. Wagner
M V P *<URL:http://dotnet.mvps.org/>
*V B * <URL:http://dotnet.mvps.org/dotnet/faqs/>

Thanks for the nice explanation. Could a funny approach would be for
try-catch to do the same with "on error resume next"? :-)

Try
<statement1>
<statement2' Exception occurs for statement2
<statement3>

Catch
<statement3' If a exception is occured in <statement2>

End Try

A bit funny...

[Herfried K. Wagner [MVP]]

"kimiraikkonen" <ki*************@gmail.comschrieb:

>Thanks for the nice explanation. Could a funny approach would be for
try-catch to do the same with "on error resume next"? :-)

Try
<statement1>
<statement2' Exception occurs for statement2
<statement3>

Catch
<statement3' If a exception is occured in <statement2>

End Try

A bit funny...

Sorry, I am not sure if you are serious :-). The code above won't be
semantically equivalent to the 'On Error Resume Next' code because it won't
catch an exception if <Statement 3throws an exception and it won't execute
<Statement 2if <Statement 1throws an exception.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Michael C]

"kimiraikkonen" <ki*************@gmail.comwrote in message
news:3a**********************************@i3g2000h sf.googlegroups.com...

Hi,
I want to find out if there's difference between "On Error Resume
Next" error handler and leaving "catch" block empty in a try-catch-end
try block to ignore exceptions which i don't approve of course but
just needed to ask.

There is nothing wrong with ignoring errors if that is the behaviour you're
after. Ignoring errors on a large block of code is really bad however.
Generally it's not necessary to ignore errors for more than 1 line of code
so the try catch would be best. I think it's best to use On Error as this is
a VB6 hangover and there is no direct translation for C#.

Michael

[Michael D. Ober]

"Michael C" <mi**@nospam.comwrote in message
news:uX**************@TK2MSFTNGP05.phx.gbl...

"kimiraikkonen" <ki*************@gmail.comwrote in message
news:3a**********************************@i3g2000h sf.googlegroups.com...

>Hi,
I want to find out if there's difference between "On Error Resume
Next" error handler and leaving "catch" block empty in a try-catch-end
try block to ignore exceptions which i don't approve of course but
just needed to ask.

There is nothing wrong with ignoring errors if that is the behaviour
you're after. Ignoring errors on a large block of code is really bad
however. Generally it's not necessary to ignore errors for more than 1
line of code so the try catch would be best. I think it's best to use On
Error as this is a VB6 hangover and there is no direct translation for C#.

Michael

You are correct that there are limited applications for On Error Resume
Next. The one application I have found (even in VB6) was during
initialization of an application. You set up default values and then call a
sub that uses On Error Resume Next so that if changes to the defaults based
on the current run time environment fail, you simply keep on going.

Mike Ober.

[Michael C]

"Guru" <ru*****@interference.nitwrote in message
news:Ox**************@TK2MSFTNGP05.phx.gbl...

So, now that you have been given 200,001 valid reasons (200,000 equality
comparisons plus your job security) in favour of using empty Catch
clauses,
please provide one single, solitary but equally valid reason for not using
them.

Well, they are slow when they do happen. I had a similar situation where an
empty string or null would cause an exception. The delay was quite
noticeable in some cases (1 sec or more). By adding in the check it became
instant. I'm not suggesting what you're saying was wrong, but you appeared
to be suggesting there was no reasons to avoid them.

Michael

[Guru]

"Michael C" <mi**@nospam.comwrote in message
news:ek**************@TK2MSFTNGP03.phx.gbl...

"Guru" <ru*****@interference.nitwrote in message
news:Ox**************@TK2MSFTNGP05.phx.gbl...

>So, now that you have been given 200,001 valid reasons (200,000 equality
comparisons plus your job security) in favour of using empty Catch
clauses,
please provide one single, solitary but equally valid reason for not
using
them.

Well, they are slow when they do happen. I had a similar situation where
an empty string or null would cause an exception. The delay was quite
noticeable in some cases (1 sec or more). By adding in the check it became
instant.

The long delay is indicative of a serious stack issue... more precisely,
stack corruption; there should be no delay. What you did was kludge your
code and leave the root cause completely unresolved. The cause is still
there in your code, lurking, waiting, ready to scribble all over your
customer's valuable data at the first opportune moment and in a completely
unexpected place elsewhere in the application.

To put that a different way, when faced with a delay in an exception, the
question you should ask yourself is, why is the code falling over at all,
not, how can you kludge your badly-written code without finding and fixing
the cause.

but you appeared to be suggesting there was no reasons to avoid them.

I suggest that the strength of every single argument for avoiding them is
inversely proportional to how crappy a programmer you are.

Touché to me.

HTH

[Michael C]

"Guru" <ru*****@interference.nitwrote in message
news:uv****************@TK2MSFTNGP05.phx.gbl...

The long delay is indicative of a serious stack issue... more precisely,
stack corruption; there should be no delay. What you did was kludge your
code and leave the root cause completely unresolved. The cause is still
there in your code, lurking, waiting, ready to scribble all over your
customer's valuable data at the first opportune moment and in a completely
unexpected place elsewhere in the application.

What a complete and utter load of rubbish.

To put that a different way, when faced with a delay in an exception, the
question you should ask yourself is, why is the code falling over at all,
not, how can you kludge your badly-written code without finding and fixing
the cause.

You really have no idea what my code was like. There was absolutely nothing
wrong with the code or the structure of it.

I suggest that the strength of every single argument for avoiding them is
inversely proportional to how crappy a programmer you are.

You clearly are an idiot.

Touché to me.

bwahahahahahahahaha

Michael

[Guru]

"Michael C" <mi**@nospam.comwrote in message
news:%2******************@TK2MSFTNGP02.phx.gbl...

"Guru" <ru*****@interference.nitwrote in message
news:uv****************@TK2MSFTNGP05.phx.gbl...

>The long delay is indicative of a serious stack issue... more precisely,
stack corruption; there should be no delay. What you did was kludge your
code and leave the root cause completely unresolved. The cause is still
there in your code, lurking, waiting, ready to scribble all over your
customer's valuable data at the first opportune moment and in a
completely
unexpected place elsewhere in the application.

What a complete and utter load of rubbish.

That is precisely what I was implicating your code of being. I'll write you
up for one "I Know You Are But What Am I" lame.

>To put that a different way, when faced with a delay in an exception, the
question you should ask yourself is, why is the code falling over at all,
not, how can you kludge your badly-written code without finding and
fixing
the cause.

You really have no idea what my code was like. There was absolutely
nothing wrong with the code or the structure of it.

There is absolutely nothing wrong with eating food you found in a dumpster,
if you're a rat.

If it is the case that "there was absolutely nothing wrong with the code"
then it necessarily follows that your earlier claim of "an empty string or
null would cause an exception" is false.

>I suggest that the strength of every single argument for avoiding them is
inversely proportional to how crappy a programmer you are.

You clearly are an idiot.

>Touché to me.

bwahahahahahahahaha

You're not very good at either programming or simple logic. Do you have any
redeeming attributes at all?

[Michael C]

"Guru" <ru*****@interference.nitwrote in message
news:O$******************@TK2MSFTNGP03.phx.gbl...

You're not very good at either programming or simple logic. Do you have
any redeeming attributes at all?

You're really not very good at being a troll, although you do try very hard.
Sorry, but I am not playing your games.

Michael

[Cor Ligthert[MVP]]

Guru,

I hope that some day the calculation of your payment will fall in that by
you not catched try block.

This is what a real proffesional programmer never would do.

Just my thought about this kind of lazy programmer stuff you show.

Cor

[Patrice]

You could easily check the MSIL code to see how on error resume next is
implemented.

Else I would do things the other way round. What are you trying to do ? Or
is it just curiosity about something you won't use ?
--
Patrice

"kimiraikkonen" <ki*************@gmail.coma écrit dans le message de news:
3a**********************************...oglegroups.com...

Hi,
I want to find out if there's difference between "On Error Resume
Next" error handler and leaving "catch" block empty in a try-catch-end
try block to ignore exceptions which i don't approve of course but
just needed to ask.

Thanks

[Michael C]

"SurturZ" <su*****@newsgroup.nospamwrote in message
news:67**********************************@microsof t.com...

While guru is a bit obnoxious in his message style, I agree with his
sentiment.

There are plenty of cases where you would correctly use ON ERROR RESUME
NEXT
or a Try...Catch with an empty catch block.

That appeared to be the only point he was correct on though. His idea that
exceptions are slow due to sloppy programming is just plain wrong. His idea
that there are no reasons to avoid a Try Catch is just plain wrong. His
general perception of himself as some sort of guru is just plain wrong.
(Guru, if you reply to this I am not going to read your response let alone
reply to you).

Michael

[Guru]

"Michael C" <mi**@nospam.comwrote in message
news:uk**************@TK2MSFTNGP05.phx.gbl...

"SurturZ" <su*****@newsgroup.nospamwrote in message
news:67**********************************@microsof t.com...

>While guru is a bit obnoxious in his message style, I agree with his
sentiment.

There are plenty of cases where you would correctly use ON ERROR RESUME
NEXT
or a Try...Catch with an empty catch block.

That appeared to be the only point he was correct on though. His idea that
exceptions are slow due to sloppy programming is just plain wrong.

Correction, you lying dribble stain. You mentioned encountering a very slow
exception and I said, and I quote:

The long delay is indicative of a serious stack issue... more precisely,
stack corruption; there should be no delay.

Freaking liar.

His idea that there are no reasons to avoid a Try Catch is just plain
wrong.

Lying little sh1t. I said, and I quote:

I suggest that the strength of every single argument for avoiding them is
inversely proportional to how crappy a programmer you are.

His general perception of himself as some sort of guru is just plain
wrong.

Huh? My name _IS_ Guru, you brain-dead cowpat. Guru Sandaramurthy. I made no
claim to being a 'guru', and you know it, you lying pillock.

(Guru, if you reply to this I am not going to read your response let alone
reply to you).

Yeah... you don't want to see if your bare-faced lies get found out, I know.

Michael, The Lying Tapeworm.

Edited.

[=?Utf-8?B?U3VydHVyWg==?=]

I for one am ignoring Guru's posts now, he's obviously a troll with no real
programming ability. In another thread he revealed that he thinks
Backhaus-Naur Form is a file protocol :lol:
--
David Streeter
Synchrotech Software
Sydney Australia
"Michael C" wrote:

"SurturZ" <su*****@newsgroup.nospamwrote in message
news:67**********************************@microsof t.com...

While guru is a bit obnoxious in his message style, I agree with his
sentiment.

There are plenty of cases where you would correctly use ON ERROR RESUME
NEXT
or a Try...Catch with an empty catch block.

That appeared to be the only point he was correct on though. His idea that
exceptions are slow due to sloppy programming is just plain wrong. His idea
that there are no reasons to avoid a Try Catch is just plain wrong. His
general perception of himself as some sort of guru is just plain wrong.
(Guru, if you reply to this I am not going to read your response let alone
reply to you).

Michael

[Guru]

"SurturZ" <su*****@newsgroup.nospamwrote in message
news:3E**********************************@microsof t.com...

>I for one am ignoring Guru's posts now, he's obviously a troll with no real
programming ability. In another thread he revealed that he thinks
Backhaus-Naur Form is a file protocol :lol:

I did no such thing, you lying spunkstain.

[=?Utf-8?B?U3VydHVyWg==?=]

TYPO: Backus-Naur, not Backhaus-Naur

BNF. Whatever that stands for :-)

--
David Streeter
Synchrotech Software
Sydney Australia
"SurturZ" wrote:

I for one am ignoring Guru's posts now, he's obviously a troll with no real
programming ability. In another thread he revealed that he thinks
Backhaus-Naur Form is a file protocol :lol:
--
David Streeter
Synchrotech Software
Sydney Australia
"Michael C" wrote:

"SurturZ" <su*****@newsgroup.nospamwrote in message
news:67**********************************@microsof t.com...

While guru is a bit obnoxious in his message style, I agree with his
sentiment.
>
There are plenty of cases where you would correctly use ON ERROR RESUME
NEXT
or a Try...Catch with an empty catch block.

That appeared to be the only point he was correct on though. His idea that
exceptions are slow due to sloppy programming is just plain wrong. His idea
that there are no reasons to avoid a Try Catch is just plain wrong. His
general perception of himself as some sort of guru is just plain wrong.
(Guru, if you reply to this I am not going to read your response let alone
reply to you).

Michael

[Michael C]

"SurturZ" <su*****@newsgroup.nospamwrote in message
news:3E**********************************@microsof t.com...

>I for one am ignoring Guru's posts now, he's obviously a troll with no real
programming ability.

Not only does he have no programming ability he's not even a very good
troll. A good troll will keep people hooked in, everyone's bailing on this
clown after a few posts.

Michael