Zitat:

Damit bekommst Du den tatsächlichen Fehlerort aber nicht die meist ebenso wichtige oder oft wichtigere Vorgeschichte, die zum Fehler geführt hat. Neben der eigentlichen Fehlerinformation (Fehlernummer u. Fehlertext) ist zur Fehlerlokalisierung fast immer hilfreich, wenn man mitbekommt, welche Subs/Functions durchlaufen worden sind, bevor es dann zum eigentlichen Fehler kam. z.B.: Ein Button_Click löst eine Prozedur "A" aus und die wiederum eine Prozedur "B" in der dann eine Prozedur "C" aufgerufen wird. Prozedur "C", erkennt einen Fehler, löst ihn erneut aus und reicht ihn damit an die aufrufende Prozedur "B" weiter. Prozedur "B" Prozedur "A" machen es genauso, auch sie reichen den Fehler an die aufrufende Prozedur weiter.

Option Explicit
 
Sub SubA()
10    Debug.Print "Hier Start  SubA"
20    On Error GoTo Fehler
30    Call SubB
40    Exit Sub
Fehler:
50    Err.Raise Err.Number, "SubA in Zeile " & Erl & "; " & Err.Source, _
    Err.Description, Err.HelpFile, Err.HelpContext
End Sub
 
Sub SubB()
10    Debug.Print "Hier Start  SubB"
20    On Error GoTo Fehler
32    Call SubC
 
40    Exit Sub
Fehler:
50    Err.Raise Err.Number, "SubB in Zeile " & Erl & "; " & Err.Source, _
    Err.Description, Err.HelpFile, Err.HelpContext
End Sub
 
Private Sub SubC()
10    Debug.Print "Hier Start  SubC"
20    On Error GoTo Fehler
33    Debug.Print 10 / 0
 
40    Exit Sub
Fehler:
50    Err.Raise Err.Number, "SubC in Zeile " & Erl & "; " & Err.Source, _
    Err.Description, Err.HelpFile, Err.HelpContext
End Sub
 
Private Sub Command1_Click()
10    On Error GoTo Fehler
20    Call SubA
 
30    Exit Sub
Fehler:
    Dim strMsg
40    With Err
50      strMsg = "Button_Click; " & .Source & vbCrLf & "Fehler: " & .Number & _
    " " & .Description
60      Debug.Print strMsg
70    End With
End Sub