Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd
Upload
3 views

ProperProgramming

"On Error Resume Next" can be a valid error handling method if used appropriately, but it may lead to hidden issues and subsequent errors that can cause significant problems. While it prevents annoying error messages, it obscures the source of errors, making debugging difficult and potentially leading to incorrect results or harmful actions. Proper error handling is generally recommended to ensure that errors are identified and addressed effectively.

Uploaded by

xlabcoder
Copyright
© © All Rights Reserved
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
3 views

ProperProgramming

"On Error Resume Next" can be a valid error handling method if used appropriately, but it may lead to hidden issues and subsequent errors that can cause significant problems. While it prevents annoying error messages, it obscures the source of errors, making debugging difficult and potentially leading to incorrect results or harmful actions. Proper error handling is generally recommended to ensure that errors are identified and addressed effectively.

Uploaded by

xlabcoder
Copyright
© © All Rights Reserved
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 1

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:
You really don’t care if the code runs properly or not, as it can't do any damage.. you hope!

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.
Last edited by si_the_geek; Feb 19th, 2008 at 01:30 PM. Reason: added "errors aren't bad" section

You might also like