I rely heavily on data from external sources. When I can't control the quality of the data sometimes strange errors occur that I would rather handle and do analysis on at a later time. The DEBUGON variable can be set on by developers during analysis. This gives developers the additional abilility to chose easily during runtime ls about an error for the analyst/developer who must inspect the problem and allow data loads to continue. I stop it and examine the runtime copy of the variable but the snippet could easily be modified to log the results in a logfile including the recordset row at fault and press on.
This will only work properly if procedures called from within this procedure also have error handling, otherwise it would give a potentially false hit. The final application code would handle all types of errors identified and DEBUGON could be set to false but be available for analysis. I recommend you use it sparingly.
DIM DEBUGON As Boolean, LOGERR As Boolean, RESUMENEXT As Boolean
HandleError: ' Error checking Layer 1 (DEV DEBUG TEST)
IF DEBUGON Then
If MsgBox(Err.Description & vbCrLf _
& "Do you want to Debug this error in GetElapsedTime?" _
& "The processing should be completed.", _
vbCritical + vbYesNo, "Data Load Notice") = vbYes Then
Stop
Resume
End If
End If
' Error Checking Layer 2 (Logging Error)
If LOGERR Then
Call HandleTheError("basDataMgmt", "GetElapsedTime", Err)
End If
' Error Checking Layer 3 (Resume Next)
If RESUMENEXT
Then Resume Next
End If
' Error Checking Layer 4 (Stardard handling)
Select Case Err.Number
If 9 Then
' Handle the 9 case
Else
GoTo Exit_Proc
End Select
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.