Antwoord.

In Visual Basic worden de constructies On Error (VB6) en Try...Catch (VB.NET) gebruikt voor foutafhandeling.

• On Error GoTo <Label> — een verouderde methode uit VB6 die een sprong maakt naar het opgegeven label bij een fout. Ondersteunt geen geneste aanroepen en kan leiden tot verwarrende code.
• Try...Catch...Finally — de moderne methode (VB.NET) die het mogelijk maakt om met uitzonderingen te werken, waarmee verschillende types fouten in verschillende Catch-blokken kunnen worden behandeld, en die altijd eindacties uitvoert in Finally.

Voorbeelden:

VB6:

Sub OpenFile()
    On Error GoTo ErrorHandler
    Open "file.txt" For Input As #1
    ' Bestand lezen
    Close #1
    Exit Sub
ErrorHandler:
    MsgBox "Fout: " & 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("Fout: " & ex.Message)
    Finally
        ' Wordt altijd uitgevoerd
    End Try
End Sub

Vrag met een addertje onder het gras.

Als er in VB6 een fout optreedt in de blok On Error Resume Next, hoe weet je waar deze precies is opgetreden en hoe kun je deze correct afhandelen?

Correct antwoord: In de modus On Error Resume Next gaat het programma verder met uitvoeren op de volgende regel. Om te controleren of er een fout is opgetreden, moet je de Err-object controleren aan het einde van de aanroep.

On Error Resume Next
' bepaalde code
If Err.Number <> 0 Then
    MsgBox "Fout: " & Err.Description
    Err.Clear
End If

Voorbeelden van echte fouten door gebrek aan kennis van deze materie.

---

Geschiedenis

Na de overstap van VB6 naar VB.NET lieten sommige foutafhandelaars de stijl van On Error GoTo staan, wat leidde tot het stilzwijgend negeren van fouten. Ze verwarden de logica van de afhandeling, waardoor gegevens in de database half leeg bleven, en de bug pas maanden later werd ontdekt.

---

Geschiedenis

Ze gebruikten Err.Clear niet, waardoor na één afgehandelde fout Err.Number niet nul bleef. Bij verdere controles dacht het programma ten onrechte dat er een nieuwe fout was opgetreden en ging het in onjuiste afhandelingspaden.

---

Geschiedenis

Bij het refactoren vergaten ze On Error Resume Next te verwijderen, waardoor fouten "stille" werden en geen berichten gaven. Het diagnosticeren van problemen nam uren in beslag, aangezien de applicatie normaal leek te functioneren, maar in werkelijkheid belangrijke gegevens verloor.