Réponse

En Visual Basic, le traitement des exceptions se fait à l'aide du bloc Try...Catch...Finally. Pour relancer une exception après l'avoir capturée — c'est-à-dire la transmettre plus loin dans la pile des appels — on utilise l'opérateur Throw ou Throw ex.

Différences :

• Throw (sans paramètre) relance l'exception actuelle, en conservant la pile des appels d'origine (Call Stack).
• Throw ex lance l'objet d'exception, mais réinitialise la pile des appels — les informations sur l'endroit où le problème est réellement survenu.

Il est recommandé d'utiliser Throw sans paramètres pour relancer correctement une exception, si elle n'a pas été modifiée.

Exemple de relance correcte :

Try
    DangerousOperation()
Catch ex As Exception
    ' Journalisation...
    Throw ' la pile des appels est conservée
End Try

Mauvaise méthode :

Try
    DangerousOperation()
Catch ex As Exception
    Throw ex ' La pile des appels est réinitialisée, le diagnostic est compliqué
End Try

Question piège

Que se passera-t-il avec la pile des appels si vous utilisez Throw ex à la place de Throw ?

En utilisant Throw sans paramètre, la pile des appels d'origine est conservée — celle où l'exception s'est produite. Si vous utilisez Throw ex, la pile commence à la ligne actuelle, et l'endroit d'origine de l'exception est perdu. Cela complique le débogage, car vous ne verrez pas dans quelle partie du code le problème s'est produit.

Exemples d'erreurs réelles dues à une méconnaissance des subtilités du sujet

---

Histoire

Dans un grand projet bancaire, les développeurs ont utilisé Throw ex pour lancer des erreurs logiques. En examinant les journaux, il était impossible de déterminer l'emplacement des exceptions, car elles manquaient de traçage correct.

---

Histoire

Dans la couche d'accès aux données, ils ont utilisé Throw pour relancer SqlException, mais dans certains cas, l'outil de formatage automatique du code l'a remplacé par Throw ex. Cela a cassé le système d'extraction automatique des données des journaux et a augmenté le temps de réponse aux incidents.

---

Histoire

Une tentative de modifier l'objet Exception et de le relancer avec Throw sans paramètre a entraîné le fait que les modifications n'ont pas été reflétées dans les journaux — seule la création explicite d'un nouvel objet d'exception avec la conservation de l'original comme InnerException a aidé.