Je recherche un moyen "élégant" de supprimer les exceptions lorsque vous appelez une méthode.
Je pense que le code suivant est trop verbeux: existe-t-il du sucre syntaxique que je peux utiliser pour dire "Je ne me soucie pas vraiment si cette méthode échoue" ? Je veux appeler la méthode et poursuivre l'exécution, peu importe ce qui se passe avec la méthode.
7 Réponses :
Je ne sais rien de plus Tersé. Je suppose que vous pouviez faire un AOP ou similaire pour quelque chose de plus fantaisie.
Ouais, quelque chose d'aopish est ce que je pensais aussi. Je ne sais tout simplement pas comment le faire réellement.
(-1) "Je ne sais pas" ne vous aide pas vraiment. "Supposons que tu puisses faire" n'est pas vraiment une réponse.
Il est rarement une bonne idée d'ignorer / d'avaler des erreurs ...
Pour permettre la réutilisation, la seule option que vous avez est quelque chose comme une méthode qui prend un mais vous n'avez pas beaucoup sauvegardé au moment où vous avez fait: p> action code>: p> static void IgnoreErrors<T>(Action action) where T : Exception
{
try { action(); } catch (T) {}
}
SomeHelper.IgnoreErrors<ParseException>(() => CallToMethodThatMayFail(3));
Y a-t-il une façon de pouvoir avoir une fonction "ignoreur" qui prend à la fois la fonction à appeler et l'errorype pour ignorer? De cette façon, vous n'ignoreriez pas les erreurs système, mais vous pourrez ignorer les «erreurs d'analyse» si vous êtes itération à travers des tonnes de données saisies par l'utilisateur.
@MARC: Tu as raison; C'est rarement une bonne idée de le faire. Cependant, dans le cas où vous voulez le faire, quelle est la meilleure façon de le faire? J'apprécie le fait que vous avez répondu aux questions. Je ne suis pas aussi appréciatiatiatiate des non-réponses pour obtenir des upvotes.
Je pourrais utiliser l'approche déléguée si j'avais beaucoup de code de manutention commun à courir dans quelques scénarios ... mais en avalant? J'utiliserais probablement juste Essayer {/ * Call Methody * /} Catch (Evidentiel exception) {}
Nope c'est-il.
Et c'est une bonne chose c'est verbeuse. Si vous réprimez une éventuelle exception, vous feriez mieux d'avoir une très bonne raison. La verbosité vous aidera ou la personne suivante qui regarde le code dans quelques mois.
Avec tout le respect due: je peux prendre la décision de savoir si j'ai une bonne raison de supprimer l'exception. Vous supposez également que ceci est un code que quelqu'un d'autre examinera réellement.
Non, il n'y a pas de meilleur moyen de le faire, et il y a une bonne raison pour cela. L'exception que vous voyez peut signifier plus que "la méthode a échoué". Cela peut signifier "le système échoue".
Vous devriez probablement au moins connecter le fait de l'échec, au cas où il s'est avéré être important après tout.
Utilisation du château, vous pouvez faire quelque chose comme ceci: et décorer la classe que vous souhaitez supprimer des exceptions pour comme ceci:
Pourquoi dites-vous que c'est trop verbeux? Si vous essayez de sauvegarder des frappes, vous pouvez simplement utiliser un extrait de code. Si vous êtes préoccupé par la lisibilité, je pense que une méthode AOOP serait moins claire pour un autre mainteneur (au moins initialement) et pour moi, cela l'emporte sur la verbosité.
La convention .NET est que les classes implémentent une méthode TryCallMayFail () et une méthode CallMayFail () et l'appelant choisit lequel à utiliser, mais la méthode TrycallMayFail () inclurait exactement ce que vous avez là.
Pas tous mais quelques-uns d'entre eux et c'est un style, je suis devenu habitué à
On dirait que vous voulez que Nasty VB aime sur une erreur de reprendre la prochaine fonctionnalité en C #!
Je pense que c'est probablement aussi élégant que possible. Passer à une fonction pour gérer l'erreur serait probablement plus déroutant. Je ne fierais pas à la manipulation des erreurs pour ignorer les erreurs. Je recommanderais de tester vos cas d'erreur attendus que vous souhaitez ignorer et de le gérer simplement dans votre code. L'élevage d'une exception est une performance plus coûteuse que la déclaration conditionnelle.
J'aimerais signaler à tout le monde il y a des scénarios de niche quand c'est une bonne idée. Comme aujourd'hui, j'ai dû modifier un code qui a lu un DataGrid créé de manière dynamique qui crée simplement des colonnes en fonction des noms de lignes à partir d'une vue SQL. De temps en temps, la vue est changée et cela fonctionne bien dans le code, cette vue peut être utilisée d'autres personnes. Pour cette page Web, j'avais besoin des colonnes nommées une certaine manière, mais je ne veux pas que le code brise si quelqu'un change la vue à l'avenir.