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