Antwort.

In Visual Basic werden zur Fehlerbehandlung die Konstruktionen On Error (VB6) und Try...Catch (VB.NET) verwendet.

• On Error GoTo <Label> — eine veraltete Methode aus VB6, die bei einem Fehler zu einer angegebenen Etikette springt. Unterstützt keine Verschachtelung und kann zu unübersichtlichem Code führen.
• Try...Catch...Finally — eine moderne Methode (VB.NET), die es ermöglicht, mit Ausnahmen zu arbeiten, verschiedene Arten von Fehlern in verschiedenen Catch-Blöcken zu behandeln und endgültige Aktionen im Finally-Block zwingend auszuführen.

Beispiele:

VB6:

Sub OpenFile()
    On Error GoTo ErrorHandler
    Open "file.txt" For Input As #1
    ' Datei lesen
    Close #1
    Exit Sub
ErrorHandler:
    MsgBox "Fehler: " & Err.Description
End Sub

VB.NET:

Sub OpenFileVBNet()
    Try
        Using reader As New StreamReader("file.txt")
            Dim line As String = reader.ReadLine()
        End Using
    Catch ex As IOException
        MsgBox("Fehler: " & ex.Message)
    Finally
        ' Wird immer ausgeführt
    End Try
End Sub

Fangfrage.

Wenn in VB6 ein Fehler im Block On Error Resume Next auftritt, wie kann man herausfinden, wo genau er aufgetreten ist, und wie kann man ihn richtig behandeln?

Richtige Antwort: Im On Error Resume Next-Modus setzt das Programm die Ausführung in der nächsten Zeile fort. Um zu erfahren, ob ein Fehler aufgetreten ist, muss das Err-Objekt nach dem Aufruf überprüft werden.

On Error Resume Next
' einige Codezeilen
If Err.Number <> 0 Then
    MsgBox "Fehler: " & Err.Description
    Err.Clear
End If

Beispiele aus der Praxis über Fehler aufgrund mangelnden Wissens über die Feinheiten des Themas.

---

Geschichte

Nach dem Umstieg von VB6 auf VB.NET wurden einige Handler im Stil von On Error GoTo beibehalten, was zu einem stillschweigenden Verschlucken von Fehlern führte. Die Logik der Verarbeitung wurde verwechselt, wodurch die Daten in der DB teilweise leer blieben, und der Fehler wurde erst Monate später entdeckt.

---

Geschichte

Err.Clear wurde nicht verwendet, sodass Err.Number nach einem behandelten Fehler nicht null blieb. Bei weiteren Überprüfungen dachte das Programm fälschlicherweise, dass ein neuer Fehler aufgetreten war, und ging in falsche Verzweigungen der Verarbeitung.

---

Geschichte

Bei der Refaktorisierung wurde vergessen, On Error Resume Next zu entfernen, sodass Fehler "verschluckt" wurden und keine Meldungen ausgegeben wurden. Die Fehlersuche dauerte Stunden, da die Anwendung normal zu funktionieren schien, tatsächlich aber wichtige Daten verlor.