Hello,

I want to improve my error handling by trapping a certain error and endng
the program if I get it. This is what I have in mind:

On Error GoTo HANDLE:

[...]

HANDLE:
        If Err.Description = "Error I want to trap"
                ThisFunction = False
        Else
                Resume Next
        End If

I want the function to return false so the calling procedure can end the
program, but if it is not that certain error, resume at the next
statement. Will the above code do what I think it will do?

Thanks,
Andrew

news:1129584278.4d9cc8d2a3c66fe6a9d7f8c6ed7b9f1f@teranews...
Show quoteHide quoteMore or less.... here's something that'll do what you want.
'========
'Minor mod.....
Terminate:
    Exit Function

HANDLE:
    If Err.Description = "Error I want to trap"
        ThisFunction = False
        Resume Terminate
    Else
        Resume Next
    End If
End Function
'========

Actually, you'll find that you'll have better results returning a Long
instead of a Boolean. True/False doesn't really tell you much. It may be all
you need but, personally, I've found that there always needs to be at least
a 3rd case (which rules out the use of a Boolean)

Most of my functions return 0 if successful, non-zero otherwise. That
non-zero value is usually the error number. Here's a very crude example....
needs a command button.
'===============
Option Explicit

Private Function MyFunc(SomeArg As Integer) As Long
   'This is a sub, coded like a function so I can
   'get success/fail results
   On Error GoTo ErrorTrap
   Dim dTmp As Double

   dTmp = 1 / SomeArg

   MsgBox dTmp

Terminate:
   Exit Function

HandleMismatch:
   'code here that may clear up the error
   MyFunc = 0 'if we cleared it
   Exit Function

PermissionDenied:
   'code here
   Exit Function

ErrorTrap:
   MyFunc = Err.Number
   Select Case Err.Number
      Case 13
         'code here to handle type mismatch
         'which can't really happen here. Just a demo
         Resume HandleMismatch
      Case 70
         'code here to handle permission denied
         'which can't really happen here. Just a demo
         Resume PermissionDenied
      Case Else
         Resume Terminate
   End Select

End Function

Private Sub Command1_Click()
   Debug.Print MyFunc(10) 'shows 0 = success
   Debug.Print MyFunc(0) 'shows 11 = Failed (because of the error)
End Sub
'===============

news:1129584278.4d9cc8d2a3c66fe6a9d7f8c6ed7b9f1f@teranews...
Show quoteHide quoteWhy don't you just test/try it? A BIG part of programming is just trying
things.  And you learn a WHOLE lot more that way.

But to answer your question, yeah. Of course, you do realize that you're
resuming to the next statement in the current procedure (the one with THIS
error handler), right? If you want to resume execution in the calling
procedure for the statement following the call to this procedure, then you
need to let the error propagate to that procedure and handle it in the
calling procedure.

One more thing....rather than checking Err.Description, check for
Err.Number. It's just better, in many ways, to deal with numbers than with
strings. If you have to, define a constant for the error number to make your
code more readable.

Should be fine... as long as you remember to set the function's return value
to "True" whenever it doesn't encounter the error you wish to trap for
aborting and have an Exit Function before your HANDLE.

news:1129584278.4d9cc8d2a3c66fe6a9d7f8c6ed7b9f1f@teranews...
Show quoteHide quote

is there a "process affinity" switch
Problem implementing an interface
Add a document to my project?
Get a string from a pointer?
Print Function
Rich Text Box
File Security Descriptor
Stopping an Event
OT: Post Programming Depression
Downside to using FileSystemObject?