Risposta

In Visual Basic, per gestire le eccezioni si utilizza il blocco Try...Catch...Finally. Per rilanciare un'eccezione dopo averla catturata — cioè trasmetterla ulteriormente nello stack delle chiamate — si utilizza l'operatore Throw o Throw ex.

Differenze:

• Throw (senza parametri) rilancia l'eccezione corrente, mantenendo lo stack delle chiamate originale (Call Stack).
• Throw ex rilancia l'oggetto eccezione, ma azzera lo stack delle chiamate — le informazioni relative al luogo reale di origine del problema.

Si consiglia di utilizzare Throw senza parametri per un corretto rilancio dell'eccezione, se non è stata modificata.

Esempio di un rilancio corretto:

Try
    DangerousOperation()
Catch ex As Exception
    ' Logging...
    Throw ' lo stack delle chiamate è mantenuto
End Try

Modo errato:

Try
    DangerousOperation()
Catch ex As Exception
    Throw ex ' Lo stack delle chiamate è azzerato, la diagnosi è difficile
End Try

Domanda insidiosa

Cosa succede allo stack delle chiamate se si utilizza Throw ex invece di Throw?

Utilizzando Throw senza parametri si mantiene lo stack delle chiamate originale — dove si è verificata l'eccezione. Se si utilizza Throw ex, lo stack inizia dalla riga corrente e il luogo originale di origine si perde. Questo complica il debug, poiché non si vedrà in quale parte del codice si è verificato il problema.

Esempi di errori reali a causa della mancanza di conoscenza delle sottigliezze del tema

---

Storia

In un grande progetto bancario, gli sviluppatori hanno utilizzato Throw ex per lanciare errori di logica. Durante l'analisi dei log, è stato impossibile determinare il luogo di origine delle eccezioni, poiché mancava una corretta tracciatura.

---

Storia

All'interno dello strato di accesso ai dati si è utilizzato Throw per rilanciare SqlException, ma in alcuni casi lo strumento di formattazione automatica del codice lo ha automaticamente sostituito con Throw ex. Questo ha rotto il sistema di estrazione automatica dei dati dai log e ha aumentato il tempo di risposta agli incidenti.

---

Storia

Un tentativo di modificare l'oggetto Exception e rilanciarlo tramite Throw senza parametri ha portato al fatto che le modifiche non si sono riflesse nei log — solo la creazione esplicita di un nuovo oggetto eccezione con la conservazione dell'originale come InnerException ha aiutato.