Je ne sais pas ce que nous pouvons faire avec une exception personnalisée, ce que nous ne pouvons pas faire avec un intégré. Cela semble une question naïve mais je n'ai vraiment aucune idée de cela. Que pensez-vous?
7 Réponses :
Il n'y a que quelques exceptions près dans .NET qui sont traitées de manière particulière, comme Filhabortexception , qui ne peut pas (normalement) être attrapé et manipulé et avalé.
Autre que cela, les types d'exception ne sont que des types d'exceptions. Vous pouvez faire à peu près la même chose avec vos propres exceptions que vous pouvez faire avec ceux définis dans le cadre.
Il est utile de créer une exception personnalisée si:
Mais généralement s'il existe déjà une exception dans le cadre que vous pourriez utiliser, il est préférable de l'utiliser au lieu de créer votre propre exception pour la même chose.
Vous pouvez l'utiliser pour la mise en œuvre de la gestion des erreurs spéciales pour des choses liées à votre application. Supposons que vous construisiez une application de banane, vous pourriez avoir un OutofbanAsException code>. Si votre application sort de bananes, vous pouvez jeter l'exception et l'attraper ultérieurement avec une manipulation des erreurs spéciales. try
{
EatBananas();
}
catch(OutOfBananasException oobe)
{
GetMoreBananas();
}
catch(Exception e)
{
TellUserAndAbort();
}
Je lance cette exception ce matin quand je m'assieds pour manger ma céréale! hehe
Je vous aime la façon dont vous utilisez "banane" par exemple ^ _ ^
Super. Maintenant j'ai faim. 99% du temps que je fais mon propre classe d'exception, je finis par le supprimer comme inutile. Dans l'exemple ci-dessus, je pourrais finir par faire de mangananas () renvoyer un succès booléen et ne pas jeter l'exception. Bien sûr, et s'il y avait 3 réponses possibles ...
Moi aussi, tony; Je ne me souviens pas d'une classe d'exception personnalisée que j'ai effectivement terminée. Mais je ne sais pas; ArgumentNulLexception ne semble tout simplement pas un remplacement adéquat pour OutofbanAsException!
La raison des différents types d'exceptions est de vous permettre de pouvoir attraper uniquement ceux que vous souhaitez avec vos gestionnaires, laissant les autres aller sur la pile. Donc, vous pouvez organiser des exceptions à des situations de certaines situations à l'occasion attendues, juste par le type d'exception.
Vous n'avez peut-être pas besoin de créer votre propre très souvent du tout, en fait. Mais si vous le faites, ce serait parce que vous devez être capable de lancer et de capturer un type d'exception plus spécifique que ce qui est disponible et peut-être avec des informations supplémentaires jointes.
BTW: Si vous souhaitez joindre plus d'informations à une exception existante, vous pouvez également utiliser la propriété (peu connue) .Data sur elle (voir blog.aboDit.com/2010/03/... )
Les exceptions personnalisées vous permettent de faire 2 choses:
Vous ne devez créer une exception personnalisée que lorsqu'il n'y a pas d'exception intégrée pour gérer si nécessaire.
A titre d'exemple, dans notre application, nous avons Nous avons aussi DatalayeException qui est lancé lorsque le Datalayer rencontre une erreur (et inclut l'exception SMS spécifique comme une exception interne).
datalayersingleresulnoneException - qui est quand on s'attendons à un seul résultat, mais il n'y a pas de résultat, et DatalayersinglerSultManyException qui s'attendons à un seul résultat mais obtenez-en plusieurs arrière. Cela nous permet d'attraper les différents problèmes une action en conséquence.
Les avantages des exceptions personnalisées ont été décrits ici, mais avant de créer votre propre, assurez-vous que le BCL n'en a pas déjà adapté à vos besoins:
http: //mikevallotton.wordpress. COM / 2009/07/08 / NET-EXCEPTIONS-TOUT-TEM / (Il y en a 141!)
Une gêne avec les exceptions intégrées est qu'il n'ya pas de distinction systématique faite entre des exceptions indiquant que
Il peut être utile d'attraper des exceptions et réthrow une des trois exceptions personnalisées (désignation définie ci-dessus) sur la base de l'emplacement de l'exception. Lorsque l'exception est retirée, passez l'exception originale en tant que paramètre InnerException.
Incidemment, il est possible de définir des exceptions génériques. Je ne suis pas tout à fait sûr des avantages et des inconvénients de le faire, et je n'ai jamais vu quelqu'un d'autre le faire. On pourrait définir par ex. une transientfaultexception (de t) qui hérite d'une (personnalisée) transientfaultexception; Une application qui attrape une délai d'accompagnement peut retirer comme une transientfaultexception (de TimeOntException) et la disposer d'une transientfaultexception (de TimeoutException) ou d'une transientfaultexception. Malheureusement, il faudrait connaître le type d'exception à apprendre à créer le générique approprié. Si on devait attraper une exception et transmettre à une méthode d'usine pour transientfaultexception, la nouvelle exception serait de type transientfaultexception (d'exception), quel que soit le type d'exception lancé à l'origine.