Catching errors

[tg2003]

Hello all,

I'm just wondering what is considered better:

Let's say I have a function that may throw an error, and I would like to catch it. I write here 2 options that I use, please tell me what you think is better. If you have some better option, please let me know. Thanks!

Option a is:

function ....()
  On error resume next
  ...
  a command that might fail

  if err.number <> 0 then 
    ....
    resume next
  endif

option b is:

function ...()
  on error goto errHandle
  ...
  a command that might fail
  ...
  exit function
errHandle:
  if err.number <> 0 then
    ...
    resume next
  endif

 

[tg2003]

oops... I forgot to close the functions

 

[CaptainD]

I use option b most of the time except I do not usually "resume next"

I've only had a few times that I let the program continue to run the code after an error.

function ...()
  on error goto errHandle
  ...
  a command that might fail
  ...
  exit function
errHandle:

MsgBox "Error doing something. Error # " & Err.Number & ", " & Err.Description, vbOKOnly, "Error"

 

[TysonLPrice]

This is what I tend to use. Sometimes I also write it to a log:

Private Sub cmdSomething_Click()
On Error GoTo ErrorHandler

    'error occurs
    
    Exit Sub
ErrorHandler:
    MsgBox "Error at cmdSomething_Click at Line # " & Erl & " (" & Err.Description & ")", , "Error: cmdSomething_Click"
End Sub

Erl contains the line number the error occured on. That's always great to know. Check out MZTools to add and remove line numbers automatically.

http://www.mztools.com/v3/download.aspx

 

[Golom]

I will tend to use Option A if I want to run some code that I believe will generate an error. For example, that is a relatively easy way to test if a dynamic array contains any elements.

Option B is my preferred method for general error trapping. I will often code IF or CASE statements in the error handler so that I can tailor the response to specific errors.

 

[ousoonerjoe]

I use a combination of the two. I also try to test everything before execution. IE: make sure the file exists before importing, make sure the connection is open and ready before firing a command or pulling a recordset, etc. The idea is to predict and adjust to certain issues that you know can happen (network goes down, file moved, etc).

"If I were to wake up with my head sewn to the carpet, I wouldn't be more surprised than I am right now.

 

[AnuragShrivastava]

The second one is the correct option only.
U can't go ahead with the first one.

Because in scenarion one even if the logic is successfull then also the code goes to exception handler.

In scenarion 2 if the logic is successful then it exits the function and u don't go into the exception handler

 

[JoeAtWork]

The second one is the correct option only.
U can't go ahead with the first one.

Because in scenarion one even if the logic is successfull then also the code goes to exception handler.

That is not correct. The code would just continue without raising errors.

You can use option A to do the specific error check. After that is complete, I would switch back to option B to catch any unforeseen errors.

function ....()
  On error resume next
  ...
  a command that might fail

  if err.number <> 0 then 
    '...Do whatever you need to resolve the error
  end if

  'Go back to normal error handling
  On Error Goto ErrHandler

Joe Schwarz
Custom Software Developer

http://www.plandev.net

 

[three57m]

>That is not correct. The code would just continue without raising errors

>Because in scenarion one even if the logic is successfull then also the code goes to exception handler.

an error may not be raised, but as AnuragShrivastava points out the algorithm within the error handler would in fact be executed. I too would avoid option A. I would also avoid resume next.

I would use:

Function AnyFunction
  On Error Goto ErrorHandler
...Function
  
  Exit Function <<<<< a requirement
  ErrorHandler:


'developer dependent resolution

End Function

 

[three57m]

>an error may not be raised, but as AnuragShrivastava points out the algorithm within the error handler would in fact be executed.

I take it back. the algorithm within the error handler would not be executed.

But I would still avoid this style

 

[strongm]

I use both constructs depending on requirements. It is always useful to have more than 1 tool for a job.

 

[JoeAtWork]

I too would avoid option A. I would also avoid resume next.

That sounds like you are basing your decision on dogma rather than the specific requirements.

The problem with option B is that there is ambiguity as to what line is causing the error. Let's say you need to handle error -99 differently depending on at what point the error occurs. If you use regular error handling you will not know at what point the error occurred, and therefore you will not know what action to take.

With option A you know exactly where the error was caused so you know exactly what actions should be taken. The code is also easier to read - it will be obvious that you are anticipating that error -99 may occur at that point. If you do this...

ErrHandler:
  If Err.Number = -99 Then
      '..do whatever to resolve it..
      Resume Next
  Else
      MsgBox "Error # " & err.number & ": " & Err.Description
  End If

...it will not be obvious to a new programmer where you anticipated -99 to occur, making the program harder to maintain.


Joe Schwarz
Custom Software Developer

http://www.plandev.net

 

[Golom]

... The code would just continue without raising errors.


Just to be picky ... the error is always raised in the sense that the error object is populated with an error.

The difference is in the flow of control.

Option "A" processes the next statement in sequence while Option "B" processes the statement following the error label.

The other difference is that Option "B" establishes an active error handler and the Err object is cleared when the code in the error handler is complete. That active error handler has implications for errors raised lower in the call stack.