Classic VB - What is wrong with using "On Error Resume Next"?

[si_the_geek]

If it is used properly, "On Error Resume Next" is a valid method of dealing with errors - but it is a method that needs to be used appropriately for the situation.

While using it means that you don't get any 'annoying' error messages that stop your program, it can easily cause much bigger problems than that, such as:

• If one error happens, then the code after that point is likely to have errors too (especially if the first error occurred while doing something like setting the value of a variable).
  
  The follow-up error(s) that occur may be simple and 'safe', such as getting the wrong result displayed on screen (but not knowing it is wrong)... or they could be much more serious, such as accidentally deleting an important file, because you had an error getting the name of the file that you wanted to delete.
  
  
• If you have made any coding mistakes (such as putting a text value into an Integer variable) then your code wont do what it is supposed to do, and you wont know why.
  
  Not only is the problem hidden from you, but so is the location of it. If you are running within VB, you would normally get the line highlighted - but with "On Error Resume Next" you wont. In fact, you wont even know that there was an error, all you will know is that you have made some kind of mistake somewhere in that routine.
  
  If you don’t know what the problem is, or where it is, how will you fix it?

What will the users of your program think if it gives them the wrong results? ..or does something nasty by mistake? They wont be happy, and they certainly wont think that you are a great programmer!


As you are reading this article, you probably think that errors are a bad thing, and so hiding them is a good idea. As you get more experience you find that this is not the case, and errors are actually a good thing - they tell you either that you have done something wrong (and why it is wrong), or that something your program relies on isn't working (but you didn't write code to deal with that).

In either case, VB wants to tell you what the problem is.. but rather than let it tell you (by using proper error handling, or none at all), or deal with the error appropriately (perhaps by exiting the routine), you have decided to put your fingers in your ears and shout 'I'm not listening!'


So when/how should I use it?
There are two kinds of situations where it is appropriate:

1. You really don’t care if the code runs properly or not, as it can't do any damage.. you hope!
   
   
2. You are expecting errors in certain part of a routine, but due to the size/structure of the routine (or what that particular piece of code does) it's better to deal with the error where it happened (by checking Err.Number immediately afterwards), rather than in an error handler that for the whole routine.

If you use the first kind regularly (more than about 10% of your error handling), I'm worried!

Using the second kind is fine, and is the ‘proper’ use. Just make sure that you revert to normal error handling after that piece of code (or have error checks all thru the routine), otherwise you are back to the problems mentioned above.


In most cases, you should be using proper error handling, as explained in this article.

[Jottum]

As an addition in those situations you want/have to use On Error Resume Next, you can avoid a lot op problems by using the On Error Goto 0 statement.

Suppose you have a user control and when you dis-enable it, you want all controls on that usercontrol to go to their dis-enabled state as well to gray them out:

Public Property Let Enabled(ByVal Setting As Boolean)
   Dim c As Control
      UserControl.Enabled() = Setting
   
   On Error Resume Next 'If no Enabled property

   For Each c In ContainedControls

      c.Enabled = Setting

   Next

   On Error GoTo 0 'Reset normal error trapping.
   
   PropertyChanged "Enabled"
End Property

HTH
Jottum

[fafalone]

I know it's generally bad to reply to 3 year old threads, but since its the FAQ section and I really feel it's missing something...

If you simply can't change over to the above mentioned better On Error methods, and are encountering a problem and can't trace the source, in the Tools -> Options -> General tab, there's an option to break on all errors which will override your On Error Resume Next statements and show you where the error is happening when you run from the IDE. Hopefully you're not calling IsIDE too much

[bahbahbah]

Hate to bump a 15 year old thread, but it's still on the front page so thought I'd ask:

Why does CodeSmart recommend "You should always use 'On Error Resume Next' error handling in 'Terminate' events."?

[OptionBase1]

I would imagine it would be to ensure that the terminate event completes.

I think OERN is like DoEvents. They can both be overly convenient and seem to make things "work better" by using them. But, if implemented haphazardly, they can cause new issues to crop up.

[wqweto]

> Why does CodeSmart recommend "You should always use 'On Error Resume Next' error handling in 'Terminate' events."?

The correct reason is that "destructors should not raise exceptions".

Using OERN is the worst thing you can do in Terminate event or even more generally using On Error statement per se in Terminate event is a disastrous approach.

The reason for this is that destructors (Terminate event) are always called when an instance goes out of scope incl. when this object deallocation happens during error handling in an unrelated procedure.

When error propagates and a Terminate event with On Error statement is called during propagation then the Err object get cleared by the On Error statement so the original error is lost *before* propagation reaching an error handler. Ouch!

Using OERN in Terminate event does not solve the problem, you just have to leave Terminate event *without* error handler and ensure every procedures the code calls has no On Error statement. That is try to prevent errors being raised at all costs without using On Error statement i.e. cannot just call VB.Collection's Item method to test if a key exsists with OERN in any code called from Terminate event.

This is one of the reason why I run VB IDE with Break on All Errors setting set and do not depend on OERN for any logical application code construction i.e. don't implement program logic using error handling/exceptions.

cheers,