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

"kimiraikko nen" <ki************ *@gmail.comschr ieb:

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]

"kimiraikko nen" <ki************ *@gmail.comwrot e in message
news:3a******** *************** ***********@i3g 2000hsf.googleg roups.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] e:

"kimiraikko nen" <kimiraikkone.. [e-mail] ieb:

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

"kimiraikko nen" <ki************ *@gmail.comschr ieb:

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

"kimiraikko nen" <ki************ *@gmail.comwrot e in message
news:3a******** *************** ***********@i3g 2000hsf.googleg roups.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.co mwrote in message
news:uX******** ******@TK2MSFTN GP05.phx.gbl...

"kimiraikko nen" <ki************ *@gmail.comwrot e in message
news:3a******** *************** ***********@i3g 2000hsf.googleg roups.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*****@interf erence.nitwrote in message
news:Ox******** ******@TK2MSFTN GP05.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.co mwrote in message
news:ek******** ******@TK2MSFTN GP03.phx.gbl...

"Guru" <ru*****@interf erence.nitwrote in message
news:Ox******** ******@TK2MSFTN GP05.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*****@interf erence.nitwrote in message
news:uv******** ********@TK2MSF TNGP05.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.

bwahahahahahaha haha

Michael