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]]

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 3> will 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.

 

[Michael D. Ober]

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 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 3> will 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.

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]]

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 3> throws an exception and it won't execute
<Statement 2> if <Statement 1> throws an exception.

 

[kimiraikkonen]

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 3> throws an exception and it won't execute
<Statement 2> if <Statement 1> throws an exception.

I'm not serious I just meant this(see comment lines):

Try
<statement1>
<statement2> ' Assume an exception occured for statement2
<statement3>

' If statement2 occurs an exception, statement1 was processed prior to
statement2 and
' it'll jump to catch block, then statement3 will be processed because
of statement2's exception
' without statements' processing sequence is interrupted.

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

End Try

It was just a funny thing about "on error resume next" 's pretty
equilavent, don't take serious

Thanks.

 

[Michael C]

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]

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.

 

[Guru]

... leaving "catch" block empty in a try-catch-end
try block to ignore exceptions which i don't approve of course

Why not? Say some code is looping through 200,000 business objects,
computing the starting position of a substring of some property in each and
every business object. Now assume that the starting point of one solitary
substring in the entire list of 200,000 business objects is -1, i.e. one
item in 200,000 is invalid, say due to operator error on some external
system that your code has no control over... now, for some undefined
business reason, the code is not interested in items that are invalid so the
code will drop those items... Also assume that, with you as
programmer-in-chief of Major Corporation X, your distressed employer has
threatened to fire your scrawny, incompetent butt if you don't improve the
performance of your code...

For Each Item As SomeType In SomeHugeListOfStrangeBusinessObjects
nLen = PerformSomeReallyWeirdCalculation(Item.SomeProperty)
iStart = PerformSomeVeryStrangeCalculation(Item.SomeOtherProperty)
Try
SomeOtherExoticList.Add(Item.SomeProperty.Substring(iStart, nLen)
Catch ex As Exception
' Do nothing... drop this item, we don't want it.
End Try
Next ' Item

That, Mister Unapproving-of-Empty-Catch-Clauses, is by far and away, much
quicker than doing 200,000 equality comparisons on iStart just to trap the
occasional, freaky business object; millions of CPU cycles quicker, in fact.

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.

Thank you.

 

[Michael C]

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]

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]

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]

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.

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.

You clearly are an idiot.


bwahahahahahahahaha

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

 

[Michael C]

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

 

[Guru]

You're really not very good at being a troll, although you do try very
hard.

I take that to mean, no, you do not have any redeeming attributes. I will
also accept your assertion as being your tacit admission to not being very
good at either programming or simple logic.

Sorry, but I am not playing your games.

Oh, but you are, even if you say you're not. You see, even though you may
now claim to have no interest whatsoever in the previous post, you did get
to the very end of it, and you did engage in a very nice act of cowardly
snippage.

HAND, spaghetti-coder.

 

[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

 

[Guru]

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.

When questioning someone-else's professionalism, it helps to be able to
spell the word otherwise you might look like a bit of an oaf, Cor. Not a
spelling lame, just a suggestion. HTH.

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

You assert that I show "lazy programmer stuff" yet you are utterly oblivious
to the concept of using Try/Catch as a versatile, robust, and flexible
programming tool that has grand purposes well beyond merely trapping the
woe-begotten side-effects of your miserably inept coding style?

<SNORT>
<GUFFAW>

 

[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 ?

 

[SurturZ]

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.

--
David Streeter
Synchrotech Software
Sydney Australia

 

[SurturZ]

Moar flame, plz