Quel est le but de lancer des sous-classes d'exception spécifiques?

Parce que vous pouvez avoir plusieurs déclarations de capture et gérer différentes erreurs différemment.

Par exemple, une exception de divisionbyzero peut inviter l'utilisateur à corriger une entrée, tandis qu'une exception FilenotFound pourrait alerter un utilisateur que le programme ne peut pas continuer et fermer le programme.

Il y a un bel article en profondeur répondant à cette question ici: Link

Plutôt que de filtrer en fonction du texte d'envoi de texte le long du flux d'erreur, vous pouvez attraper plusieurs types d'exceptions. Chacun peut avoir un moyen très spécifique d'effectuer une récupération. Le texte est juste là pour fournir à l'utilisateur ou à débogger des commentaires, mais le programme se soucie du type d'exception. Pour la même raison, il existe un polymorphisme pour les classes créées par l'utilisateur, il y a des exceptions.

Il est beaucoup plus facile d'inclure plusieurs déclarations de capture pour différents types d'exception que d'analyser le texte de message pour comprendre ce qui doit être fait pour gérer correctement le problème.

Les différentes sous-classes d'exception portent une signification sémantique - une erreur argumentation indique un problème différent d'un problème qui génère une divisionbyzeroexception et le programmeur peut gérer ces problèmes différemment. De plus, les sous-classes peuvent définir des propriétés ou des méthodes supplémentaires pouvant aider à diagnostiquer ou à manipuler le problème, si le programmeur choisit de les utiliser.

try {
    Do();
}
catch (MyException)
{
    // reaction on MyException
}
catch (AnotherException)
{
    // another reaction on AnotherException
{
// SomeException will not be caught


void Do()
{
    if (...)
        throw new MyException();
    else if (...)
        throw new AnotherException();
    else
        throw new SomeException();
}

Dans une hiérarchie exceptionnelle bien conçue, avoir différents types d'exceptions permettant d'avoir des déclarations de capture qui prennent des mesures différentes dans différentes circonstances. Idéalement, une famille d'exceptions émergerait d'une fonction si l'action particulière ne pouvait être achevée, mais les invariants de classe qui auraient dû être applicables avant que l'action ait été tentée probablement tenue, à l'exception de celles impliquées par l'échec de l'action. Par exemple, la méthode Get-Object d'une collection devrait lancer une exception de cette famille si la collection semble valide mais l'objet demandé n'existe pas.

Si une fonction échoue de manière à ce que les invariants de classe ne soient pas tenus lorsqu'il a été appelé, ou ne contiennent plus après son retour, il devrait lancer une exception d'une famille différente. Notez qu'il peut être approprié pour une fonction capturer une exception de la première famille et de Retirhow comme la seconde, si la seule façon dont l'exception serait survenue serait si les invariants ont été violés. Il peut également être approprié à l'occasion d'attraper une exception du deuxième type et de lancer l'une des premières, si les exceptions provenaient d'un objet qui ne seront jamais utilisées après la retouche de la fonction.

Si les choses sont vraiment énormes (par exemple, exception exceptionnelle, cpucatchingfireException, etc.) qui devrait être une autre hiérarchie séparée des deux premières.

Les exceptions existantes ne suivent pas ce modèle, mais on pourrait l'utiliser pour toutes les nouvelles exceptions que l'on crée.

directement à partir de msdn - Manipulation d'exception :

envisager d'attraper des exceptions spécifiques lorsque vous comprenez pourquoi il sera lancé dans un contexte donné.

Vous ne devez attraper que ces exceptions que vous pouvez récupérer. Par exemple, un FilenotFoundException résultant d'une tentative d'ouverture d'un fichier inexistant peut être géré par une application car elle peut communiquer le problème à l'utilisateur et permettre à l'utilisateur de spécifier un nom de fichier différent ou Créez le fichier. Une demande d'ouverture d'un fichier qui génère un exécutenanceeneexception ne doit pas être traitée car la cause sous-jacente de l'exception ne peut être connue avec aucun degré de certitude et que l'application ne peut s'assurer qu'elle est prudente de continuer à exécuter.

Ne pas trop excuser Catch , car jetant une autre exception à partir d'un bloc de capture réinitialisera la trace de la pile et entraînera la perte des informations de débogage importantes, comme une fois de nouveau MSDN suggère:

Ne pas surutiliser. Des exceptions doivent souvent être autorisées à propager la pile d'appels.

Accrocher des exceptions que vous ne pouvez pas légitimement gérer les informations critiques de débogage critiques.

À la fin, la prise d'une exception devrait être une exception pour la gestion des exceptions spécifiques que vous vous attendez à survenir sous certains scénarios communs où vous souhaitez enregistrer ou avoir un comportement spécifique lors de la prise d'exception, sinon simplement Jetez E-le loin, comme Eric Lippert recommande lui-même sur son blog (voir trop de réutilisation article). xxx

au lieu de: xxx

enfin, une exception n'est pas obligatoire de proposer certaines spécificités en tant que propriétés ou méthodes supplémentaires ou quelle que soit le nom de celui-ci qui sit elle-même, vous permettant de filtrer votre prise sur un type d'exception spécifique.

edit # 1

Un autre lien intéressant sur la manipulation des erreurs sur l'Eric Lippert's Blog: exceptions vexing .