ansaurus

Question

Answer 1

+1 A:

Almost never - unless used consciously for example on a line where a successful call will set a particular return value, and the subsequent code handles the return value to cater for the error case.

David M 2010-05-03 10:52:14

Answer 2

+2 A:

I have found it useful in functions where an error would not warrant the user being interrupted with the issue. A good example is in the resize event. If you make a mistake or there's a problem in the resize event then you probably don't want the user to see this, as it probably wouldn't affect functionality.

I would say in general, use it sparingly.

pm_2 2010-05-03 20:16:54

+1. Use it sparingly and keep the scope as short as possible. Here's a nice story about how `On Error Resume Next` turns a little typo into an evil bug that only showed up on the customer's machine and was tricky to debug http://www.developerfusion.com/code/4325/on-error-resume-next-considered-harmful/

MarkJ 2010-05-04 12:04:25

+1: A `Resize` method is usually an OK use case for `On Error Resume Next` as mentioned here. It can also be useful for cases where you can't avoid an error being raised, but want to handle it differently, such as when you try to access a non-existent item in a `Collection`. Since there is no `Exists` method on the `Collection` class, trying to access an item in the collection and catching any resulting error is the only way to find out if the item exists or not.

Mike Spross 2010-05-06 03:04:49

On that note, `On Error Resume Next` tends to be most useful when you don't want to be jumping to a bunch of different error-handling labels in your code, in cases where you may have to handle a number of different errors at different points in the code. `On Error Resume Next` lets you write your error-handling logic "in sequence" with your normal code. `On Error Resume Next`...Try to do something that might error out...check `Err.Number` to see if an error occurred and handle appropriately...repeat.

Mike Spross 2010-05-06 03:08:11

I have the IDE set to break on all errors, so even if you used an On Error Resume Next, it would still stop while you're debugging in the IDE and you will be able to fix the root cause. (Just extra FYI)

Scott Whitlock 2010-05-07 02:29:11

@Scott: While I agree that is the correct behavior, I wish they added an additional option for "Break on all errors except where I put On Error Resume Next specifically beacuse I don't want to get a million error pop-ups while debugging".

Mike Spross 2010-05-29 05:40:10

Answer 3

+3 A:

It is perfectly reasonable to use On Error Resume Next to implement local structured error handling. This involves testing for an exception and acting on it of course, as well as disarming the mechanism afterward. Example:

On Error Resume Next
GetAttr strFilePath
If Err Then
    On Error GoTo 0
    'Deal with "no file" scenario.
Else
    On Error GoTo 0
    'Open and process the file.
End If

That's just a simple example where only one sort of exception is expected. In some cases it is necessary to test Err.Number for specific values and take different actions based on them.

The unstructured approach based on GoTo label can often work as well, but it is hardly superior in most instances. In VBScript the pattern shown above is the only form of exception handling you even have since there are no GoTos or labels.

What's objectionable is arming explicit exception testing at the head of every procedure and ignoring it... a sort of Trust the Force, Luke approach to trying to mask coding errors.

Bob Riemersma 2010-05-05 11:36:38

ansaurus

tags:

views:

answers:

Trap error or 'Resume Next'

related questions