Réponse.

Dans Visual Basic, pour la gestion des erreurs, on utilise les constructions On Error (VB6) et Try...Catch (VB.NET).

• On Error GoTo <Label> — méthode obsolète de VB6, qui permet de basculer vers un label spécifié en cas d'erreur. Ne prend pas en charge l'imbrication, ce qui peut entraîner du code confus.
• Try...Catch...Finally — méthode moderne (VB.NET), qui permet de travailler avec des exceptions, offrant la possibilité de gérer différents types d'erreurs dans différents blocs Catch et effectuant toujours des actions finales dans Finally.

Exemples :

VB6:

Sub OpenFile()
    On Error GoTo ErrorHandler
    Open "file.txt" For Input As #1
    ' Lire le fichier
    Close #1
    Exit Sub
ErrorHandler:
    MsgBox "Erreur : " & 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("Erreur : " & ex.Message)
    Finally
        ' Toujours exécuté
    End Try
End Sub

Question piège.

Que faire si une erreur se produit dans le bloc On Error Resume Next en VB6, comment savoir où elle s'est produite et comment la gérer correctement ?

Réponse correcte : Dans le mode On Error Resume Next, le programme continue son exécution à la ligne suivante. Pour savoir s'il y a eu une erreur, il faut vérifier l'objet Err à la fin de l'appel.

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

Exemples d'erreurs réelles dues à un manque de compréhension des subtilités du sujet.

---

Histoire

Après la migration de VB6 à VB.NET, certains gestionnaires ont été conservés dans le style On Error GoTo, ce qui a conduit à une absorption implicite des erreurs. La logique de gestion a été confondue, ce qui a laissé des données dans la base de données incomplètes, et le bug n'a été découvert qu'après des mois.

---

Histoire

Err.Clear n'a pas été utilisé, résultant du fait qu'après une erreur gérée, Err.Number restait non nul. Lors des vérifications ultérieures, le programme considérait à tort qu'une nouvelle erreur s'était produite et suivait de fausses branches de traitement.

---

Histoire

Lors de la refactorisation, l'On Error Resume Next a été oublié, ce qui a conduit à des erreurs "absorbées" sans afficher de messages. Le diagnostic des problèmes a pris des heures, car l'application semblait fonctionner normalement, mais en réalité, elle perdait des données importantes.