Odpowiedź.

W Visual Basic do obsługi błędów używane są konstrukcje On Error (VB6) oraz Try...Catch (VB.NET).

• On Error GoTo <Etykieta> — przestarzały sposób z VB6, realizujący przejście do wskazanej etykiety w przypadku wystąpienia błędu. Nie wspiera zagnieżdżeń, co może prowadzić do nieczytelnego kodu.
• Try...Catch...Finally — nowoczesny sposób (VB.NET), który pozwala na obsługę wyjątków, daje możliwość obsługi różnych typów błędów w różnych blokach Catch oraz zawsze wykonuje działania końcowe w bloku Finally.

Przykłady:

VB6:

Sub OpenFile()
    On Error GoTo ErrorHandler
    Open "file.txt" For Input As #1
    ' Odczyt pliku
    Close #1
    Exit Sub
ErrorHandler:
    MsgBox "Błąd: " & 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("Błąd: " & ex.Message)
    Finally
        ' Zawsze wykona się
    End Try
End Sub

Pytanie z pułapką.

Jeśli w VB6 wystąpi błąd w bloku On Error Resume Next, jak dowiedzieć się, gdzie dokładnie wystąpił i jak go poprawnie obsłużyć?

Prawidłowa odpowiedź: W trybie On Error Resume Next program kontynuuje wykonywanie od następnej linii. Aby sprawdzić, czy wystąpił błąd, należy zweryfikować obiekt Err po zakończeniu wywołania.

On Error Resume Next
' jakiś kod
If Err.Number <> 0 Then
    MsgBox "Błąd: " & Err.Description
    Err.Clear
End If

Przykłady rzeczywistych błędów z powodu nieznajomości niuansów tematu.

---

Historia

Po przejściu z VB6 na VB.NET część obsług błędów pozostawiono w stylu On Error GoTo, co skutkowało niejawny „przełykaniem” błędów. Pomyłka w logice obsługi prowadziła do tego, że dane w bazie danych pozostawały niekompletne, a błąd został wykryty dopiero po miesiącach.

---

Historia

Nie używano Err.Clear, w wyniku czego po jednej obsłużonej błędzie Err.Number pozostawał różny od zera. Przy kolejnych sprawdzeniach program błędnie uważał, że wystąpił nowy błąd, i przechodził w niewłaściwe gałęzie obsługi.

---

Historia

Podczas refaktoryzacji zapomniano usunąć On Error Resume Next, przez co błędy były „przełykane” i nie wyświetlały żadnych komunikatów. Diagnostyka problemów zajmowała godziny, ponieważ aplikacja wyglądała na działającą prawidłowo, ale w rzeczywistości traciła ważne dane.