Je ne veux pas attraper une exception. Puis-je le faire en quelque sorte?
Puis-je dire quelque chose comme ceci: ?
6 Réponses :
try
{
}
catch (Exception ex)
{
if (ex is CustomExceptionA)
{
throw;
}
else
{
// handle
}
}
Vous pouvez le filtrer:
try
{
}
catch (CustomExceptionA) { throw; }
catch (Exception ex) { ... }
lancer au lieu de lancer e laisserait la trace de la pile principalement intakt.
@Danielhilgarth à droite, changé. Mais cela dépend de ce que vous voulez imho.
Tout d'abord, c'est une mauvaise pratique d'attraper une exception à moins de votre loger et de le rejeter. Mais si vous devez, vous devez prendre votre exception personnalisée et le jeter comme si:
try
{
}
catch (CustomExceptionA custome)
{
throw custome;
}
catch (Exception e)
{
// Do something that hopefully re-throw's e
}
try
{
// Explosive code
}
catch (CustomExceptionA){ throw; }
catch (Exception ex)
{
//classic error handling
}
Vos solutions sont meilleures que mon, je dois dire!
Après avoir été scolarisé par @servy dans les commentaires, j'ai pensé à une solution qui vous laissera faire [ce que je pense] que vous voulez faire. Créons une méthode Ceci peut alors être appelé comme ceci: ignoreExceptions pour () qui ressemble à ceci:
@Servy Il me semble que l'OP souhaite que certaines exceptions soient ignorées et que d'autres manipulées, le code continuant de fonctionner après les ignorées. Plusieurs autres ont affiché des moyens de lancer des exceptions à un niveau supérieur, mais aucun n'atteint cette fonctionnalité. Si l'OP voulait savoir comment repenser des exceptions à un niveau supérieur, il semble qu'il l'aurait demandé de cette façon. Notez que le code à l'intérieur du Essayez ne sera pas poursuivi après l'exception.
L'OP a demandé un moyen de ne pas attraper un certain type d'exception. L'effet de ne pas attraper est que l'exception est remontée jusqu'à ce qu'elle frappe un autre bloc d'essai / attraper, non pas qu'il continue d'exécuter au point où l'exception a été lancée. Il n'a pas demandé comment empêcher l'exception d'être lancée en premier lieu. Bien que techniquement, les solutions fournies attrapent l'exception personnalisée, l'effet est que l'exception semble jamais avoir été attrapée car elle est renvoyée.
@Servy la seule raison logique que quiconque voudrait réthrow une exception consiste à l'attraper ailleurs. S'il voulait l'attraper ailleurs, il ne demanderait pas comment ne pas attraper des exceptions. Je suppose qu'il a une exception à laquelle il s'attend à être jeté, mais l'exception étant jetée ne provoque pas nécessairement aucun problème. Peut-être quelque chose comme Var une session ["tout ce que"]; Si (A == NULL) A = Par défaut (A); Si la session jette un nullref ou quelque chose qui se soucie, nous voulons toujours obtenir la valeur par défaut. Ma réponse est la seule qui le permet.
La seule raison logique que quiconque voudrait réthrow une exception consiste à l'attraper ailleurs que, ou c'est une exception fatale qui devrait planter l'application. Notez qu'il n'a rien dit qui impliquerait de vouloir vouloir le comportement que vous avez demandé. Si c'est ce qu'il veut, alors il aura besoin de le demander. De plus, votre réponse n'implique pas que l'exception ne soit pas lancée, ce qui est ce que vous semblez penser que l'OP veut. Vous répondez essentiellement, "attrape explicitement toutes les exceptions autres que l'exception personnalisée qui étend exception ". Ce n'est pas une option particulièrement pratique.
@Servy étant donné que la question pose "Comment puis-je attraper toutes les exceptions, à l'exception d'un certain?", Je dirais que "attraper toutes les exceptions autres que l'exception personnalisée" ressemble à une jolie réponse à la place, non? En supposant qu'il traite d'une exception fatale, vous devez deviner autant que je suis. Alors quelle réponse est plus correcte? Je ne sais pas, cela dépend de ce que veut réellement la puissance. Ma réponse donne au profit de ne pas encourager la mauvaise pratique de codage. Les exceptions devraient (presque) ne jamais être retirées. Il vaut mieux les laisser buller jusqu'à quelque part qu'ils peuvent être manipulés.
S'il n'y a que deux ou trois autres exemples possibles, votre approche n'est pas si mauvaise. Et s'il y a 10, ou 50, ou plus? Et si vous ne savez pas quelles exceptions pourraient éventuellement être lancées, ou si vous appelez au code tiers qui pourrait potentiellement lancer des exceptions différentes lorsque les versions changent? Comment réthraine une exception pire pire que la laissant bouillir. Il n'y a pratiquement aucune différence que je peux penser entre les deux options.
@Servy Eh bien ce que vous oubliez, c'est que si je suis correct dans mon hypothèse des besoins de l'OP, il n'a pas un autre choix (en supposant qu'il ne veuille pas changer l'architecture). S'il a un million d'exceptions différentes pour traiter et veut ignorer une seule d'entre elles, il devrait changer sa structure plutôt que de travailler autour des exceptions. Et logique / performance sage, vous avez raison - il n'y a pratiquement aucune différence. C'est juste une question de norme de codage. Des exceptions ne doivent être attrapées que lorsqu'il y a quelque chose qui peut être fait à ce sujet à ce moment-là et là.
J'applique la logique de ne pas attraper des exceptions que vous ne pouvez pas gérer que pour les exceptions qui ne sont pas remerciées. Si vous le rejoignez, vous indiquez clairement que vous n'avez pas résolu l'exception.
@Servy mais alors pourquoi retirez-le? Pourquoi ne pas simplement laisser tomber bulle sans avoir à ajouter du code inutile?
Cela bouillonne dans les deux cas. Dans l'acte de repousser, il est conçu pour empêcher l'ajout de code inutile. Je sens qu'un bloc de capture avec un lancer; avec un bloc de capture qui gère toutes les autres exceptions a beaucoup moins de code redondant, puis un bloc qui a une douzaine de blocs de capture différents avec le même contenu. Il est également plus risqué et moins à maintenir à mesure que de nouvelles exceptions devront être ajoutés au fil du temps et il est facilement possible de manquer une. Comment pensez-vous que tous ces blocs de capture seront moins code?
@Servy, je faisais réellement parler dans un sens général. Dans ce cas particulier, ce n'est pas une question dont on est "meilleur", c'est une question dont une fonctionne . Et, à nouveau en supposant que je suis correct sur la direction de l'OP, ma réponse est la seule solution que fonctionne . Je n'aime pas avoir plusieurs blocs de capture non plus, et si c'était moi, je trouverais un moyen de restructurer mon code pour ne pas avoir besoin d'eux, mais dans cet exemple, c'est le seul et unique moyen de le faire.
Si votre code manque un bloc de capture pour toute exception ou n'est pas maintenu correctement car l'ensemble des exceptions possibles change alors que votre code ne fonctionnera pas. Si c'est correct, alors les deux vont fonctionner de manière égale. Qu'en est-il de repousser l'exception ne fonctionne pas? Comment l'effet de la repousser-t-il différent de ne pas le saisir en premier lieu?
@Servy Lorsque vous attrapez une exception, que vous réticulez ou non, le code va arrêter l'exécution au moment de l'exception. Si vous ne attrapez-le, cela continuera à courir. Si c'était son intention, il y a une énorme différence.
Non, ce ne sera pas. S'il y a une exception et que vous ne l'attrapez pas, l'exécution s'arrêtera, la méthode retournera le contrôle à la méthode d'appel, ce qui l'attrapera ou le contrôle de son appelant, etc. jusqu'à ce que l'application se bloque ou à l'exception. est capturé. Ignorer l'exception ne fait pas que le programme continue comme si cela ne se produisait jamais, il fait battre le programme.
@Servy bon point. J'ai eu mes fils croisés. Ok, va éditer maintenant.
Commencer avec C # 6, vous pouvez utiliser un Filtre d'exception :
try
{
// Do work
}
catch (Exception e) when (!(e is CustomExceptionA))
{
// Catch anything but CustomExceptionA
}
Merci pour cela. C'est clairement le meilleur moyen. Il n'éclante pas la pile d'origine comme lancer; fait.
attraper et retirer votre exception blanchie?
Pourrait vous aider plein pour vous Stackoverflow.com/questions/3542659/...