Risposta.

In Visual Basic, per la gestione degli errori si utilizzano le strutture On Error (VB6) e Try...Catch (VB.NET).

• On Error GoTo <Label> — metodo obsoleto di VB6, implementa un salto all'etichetta specificata in caso di errore. Non supporta la nidificazione, può portare a codice confuso.
• Try...Catch...Finally — metodo moderno (VB.NET) che consente di lavorare con le eccezioni, offre la possibilità di gestire diversi tipi di errori in diversi blocchi Catch e assicura l'esecuzione delle azioni finali in Finally.

Esempi:

VB6:

Sub OpenFile()
    On Error GoTo ErrorHandler
    Open "file.txt" For Input As #1
    ' Lettura del file
    Close #1
    Exit Sub
ErrorHandler:
    MsgBox "Errore: " & 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("Errore: " & ex.Message)
    Finally
        ' Eseguito sempre
    End Try
End Sub

Domanda ingannevole.

Se in VB6 si verifica un errore nel blocco On Error Resume Next, come sapere esattamente dove è avvenuto e come gestirlo correttamente?

Risposta corretta: In modalità On Error Resume Next, il programma continua l'esecuzione sulla riga successiva. Per sapere se si è verificato un errore, è necessario controllare l'oggetto Err al termine della chiamata.

On Error Resume Next
' codice qualche
If Err.Number <> 0 Then
    MsgBox "Errore: " & Err.Description
    Err.Clear
End If

Esempi di errori reali a causa della mancata comprensione delle sottigliezze dell'argomento.

---

Storia

Dopo il passaggio da VB6 a VB.NET, alcune gestori sono stati mantenuti nello stile On Error GoTo, il che ha portato a opacità degli errori. Hanno confuso la logica di gestione, il che ha fatto sì che i dati nel database rimanessero parzialmente vuoti, e il bug è stato scoperto solo dopo mesi.

---

Storia

Non hanno usato Err.Clear, quindi dopo un errore gestito Err.Number è rimasto diverso da zero. Durante ulteriori controlli, il programma pensava erroneamente che si fosse verificato un nuovo errore e seguiva rami di gestione errati.

---

Storia

Durante il refactoring, hanno dimenticato di rimuovere On Error Resume Next, il che ha portato a "inginocchiamento" degli errori e a nessun messaggio emesso. La diagnosi dei problemi ha richiesto ore, poiché l'applicazione sembrava funzionare normalmente, ma in realtà perdeva dati importanti.