Hi TC,
I've done quite a bit of work with VB error handling. I've seen the symptom
you describe when an error handler calls a method which has it's own error
trap (On Error statement) . For this reason we do very little inside our own
error handlers aside from calling a few of our own methods which are
specifically designed for use inside an error handler. (Similar in concept
to what you are doing. I see nothing wrong with this approach per se.)
That being said, I see the commented On Error trap in your error handler
method, along with the error handler in that method which is ostensibly
never being called. I'm confused. Why comment out the error trap, and retain
a 'dead' error handler? Are you sure that the source code is absolutely
faithful to the binary in which you are seeing these symptoms?
Second, you seem to be missing an Exit Sub before your error handlers. I see
what you are trying to do by trapping for Err.Number = 0 in your error
handlers however typical code construction would prevent entry into the
handler to begin with unless an error has occurred. an Exit Sub just before
your handler will go a long way toward code clarity in this respect.
Another interesting thing you are doing is passing the Err object as a
parameter. I wonder what effect that is having. In our error handling
methods we pass the Err properties we are interested in as separate
parameters (e.g. Err.Number, Err.Description, etc.).
Hope this helps,
- Joe Geretz -
Hey Jezebel,
I don't think that you under stood my question.
For what it's worth, your error handler does not need to be that complicated
nor do you need to repeat all of that code in all of your routines.
See concrete example below:
' This routine removes all references, etc. and ends the current user
session
Public Sub QuitSession()
Const constrROUTINE_NAME As String = "QuitSession"
On Error GoTo ErrorHandler
' If all objects have been destroyed, exit the routine
If g_objThisAddIn Is Nothing Then
GoTo ErrorHandler
End If
If Not g_objThisAddIn.Soap Is Nothing Then
With g_objThisAddIn.Soap
If .IsConnected = True Then
.SoapMethod = EndSession
.SoapMethodName = g_constrEND_SESSION
'disconnect the session!
.CallSoapMethod
.CompleteSoapCall
End If
End With
End If
' Save settings
SaveToolbarSettings
' Destroy addin instance
Set g_objThisAddIn = Nothing
ErrorHandler:
Select Case Err.Number
Case 0 ' Do Nothing
' Unexpected error has occurred
Case Else
Call AppMessageBoxes(g_constrMODULE_AND_METHOD &
m_constrMODULE_NAME & g_constrDOUBLE_SPACE & constrROUTINE_NAME, _
vbExclamation + vbOKOnly +
vbMsgBoxSetForeground, g_constrERROR, , , Err)
End Select
End Sub
Below is a generic errorhandler and messagebox handler for an entire
application:
Public Sub AppMessageBoxes(ByVal strPrompt As String, _
ByVal lngButtons As Long, _
ByVal strTitle As String, _
Optional ByVal strHelpfile As String, _
Optional ByVal lngContext As Long, _
Optional ByVal objErr As Object, _
Optional ByRef intVal As Integer)
Const constrROUTINE_NAME As String = "AppMessageBoxes"
' There is no error trapping in this routine because
' error trapping will clear the error object that
' is passed to this error handling routine upon entrance
' On Error GoTo ErrorHandler
If Not objErr Is Nothing Then
Call MsgBox(g_constrERROR & objErr.Number & vbCr &
objErr.Description & vbCr & vbCr & strPrompt, _
lngButtons, strTitle)
' Log the error
If g_objThisAddIn.CurrentUser.PrintErrorLog = True Then
LogError strPrompt, objErr.Number, objErr.Description
End If
ElseIf intVal = 0 Then
intVal = MsgBox(strPrompt, lngButtons, strTitle)
Else
Call MsgBox(strPrompt, lngButtons, strTitle)
End If
ErrorHandler:
Select Case Err.Number
Case 0 ' Do Nothing
' Unexpected error has occurred
Case Else
End Select
' Clear any unhandled errors
If Err.Number <> 0 Then
Err.Clear
End If
End Sub
Lastly, my actual question was not answered which was:
Has anyone seen or does anyone know the cause of an err object's Number
property being reset when it is passed into a handling routine?
Technically, this should not happen because the object has not been released
from memory within the original calling routine.
Thanks & Regards,
Todd
