Pourquoi créer des exceptions personnalisées ?

Question

Pourquoi devons-nous créer des exceptions personnalisées dans .NET?

Answer 1

Les exceptions douanières spécifiques vous permettent de séparer les différents types d'erreurs pour vos instructions catch. La construction commune pour la gestion des exceptions est la suivante :

try
{}
catch (Exception ex)
{}

Cela attrape tous les exceptions, quel que soit le type. Toutefois, si vous avez des exceptions personnalisées, vous pouvez avoir des gestionnaires distincts pour chaque type :

try
{}
catch (CustomException1 ex1)
{
    //handle CustomException1 type errors here
}
catch (CustomException2 ex2)
{
    //handle CustomException2 type errors here
}
catch (Exception ex)
{
    //handle all other types of exceptions here
}

Ainsi, les exceptions spécifiques vous permettent d'avoir un niveau de contrôle plus fin sur votre traitement des exceptions. Cet avantage est partagé non seulement par les exceptions personnalisées, mais aussi par tous les autres types d'exceptions des bibliothèques système .NET.

Answer 2

J'ai récemment consacré un long article de blog à ce sujet :

http://blogs.msdn.com/jaredpar/archive/2008/10/20/custom-exceptions-when-should-you-create-them.aspx

Le fond du problème se résume à : Ne créez une exception personnalisée que si l'une des conditions suivantes est remplie

1. Vous attendez en fait que quelqu'un s'en occupe.
2. Vous voulez enregistrer des informations sur une erreur particulière

Answer 3

Donc tu peux aussi les lancer toi-même, puis les attraper et savoir exactement ce qu'ils signifient.

De plus, si vous créez une bibliothèque de classes, un cadre ou une interface, il est souvent utile de créer une BaseException dont les autres exceptions de votre code héritent. Ainsi, lorsque votre code soulève des exceptions, les programmeurs qui l'utilisent peuvent rapidement connaître la source de l'exception.

Answer 4

Parce qu'il peut rendre vos intentions claires, et vous pouvez également suivre les utilisations en utilisant la fonctionnalité IDE. Disons que vous avez un système backend personnalisé appelé "FooBar" et que vous créez une "FooBarDownException", vous pouvez suivre les utilisations de cette exception pour identifier toute logique personnalisée que votre application contient parce que FooBar est hors service. Vous pouvez choisir d'attraper ce type spécifique d'exception et d'ignorer les autres, en évitant les surcharges et la logique conditionnelle dans les gestionnaires d'exception. Il s'agit simplement d'une autre version du typage fort. Cela signifie également que vous pouvez éviter les commentaires dans votre code parce que l'exception a un caractère intention révélation du nom .

Answer 5

C'est pour la même raison que vous créeriez différents codes de sortie pour une application non .NET : pour spécifier différentes erreurs spécifiques à l'application. Comme... ConnectionBrokenException ou hum... UserSmellsBadException ... ou quelque chose comme ça.

De cette façon, vous pouvez savoir exactement ce qui a mal tourné et agir en conséquence. Par exemple, si vous essayez d'envoyer des données et que la classe de transport de données renvoie une erreur de type ConnectionBrokenException vous pouvez faire apparaître une boîte de dialogue de reconnexion et essayer de vous reconnecter. La méthode de reconnexion renverrait alors un ConnectionTimeoutException si elle se termine, et vous pouvez à nouveau agir de manière appropriée.