En Visual Basic .NET, vous pouvez créer des types d'exceptions personnalisés pour indiquer de manière plus explicite les erreurs spécifiques survenues dans l'application. Pour cela, il faut hériter d'une nouvelle classe à partir de System.Exception (ou d'un de ses sous-types) et, si nécessaire, ajouter de nouvelles propriétés pour transmettre des informations supplémentaires.
Les exceptions personnalisées permettent de rendre le code plus lisible et maintenable, surtout si vous avez besoin d'un traitement spécifique pour certains scénarios métier.
Exemple :
Public Class InvalidUserNameException Inherits ApplicationException Public Sub New(message As String) MyBase.New(message) End Sub End Class ' Utilisation : Sub ValidateUserName(userName As String) If userName = "" Then Throw New InvalidUserNameException("Le nom d'utilisateur ne peut pas être vide") End If End Sub
Question : « Peut-on simplement lancer une chaîne avec Throw "Erreur" en Visual Basic, et cela sera-t-il traité par Try...Catch ? »
Réponse : Non, ce n'est pas possible. L'opérateur Throw exige un objet de type Exception. Essayer de lancer une chaîne (Throw "err") entraînera une erreur de compilation. Vous devez toujours créer une nouvelle instance de la classe Exception ou de l'un de ses sous-types.
Exemple de code incorrect :
' Cela entraînera une erreur ! Throw "Erreur!"
Exemple de code correct :
Throw New Exception("Erreur !")
Histoire :
Dans un grand projet, l'un des développeurs lançait des exceptions avec
Throw "Données incorrectes !". Cela entraînait des erreurs de compilation en production, car le code n'avait pas passé la vérification statique. L'absence de gestion appropriée des exceptions a retardé la sortie d'une semaine - il a fallu rechercher et réécrire tous les cas d'utilisation de throw avec des chaînes dans le code.
Histoire :
L'équipe créait des exceptions personnalisées sans ajouter de constructeur avec le paramètre InnerException. Lors du diagnostic d'erreurs complexes, la pile d'appels était perdue en raison de l'impossibilité de «nicher» l'exception d'origine. En conséquence, il était difficile de trouver la cause initiale du problème.
Histoire :
Dans une application multimédia, l'exception personnalisée était utilisée trop souvent et à mauvais escient (par exemple, à chaque saisie de données incorrectes). En conséquence, les performances du système ont chuté - car la génération d'exceptions est opérationnellement coûteuse. Après une revue, certaines de ces exceptions ont été remplacées par des vérifications de conditions normales.