J'ai pris l'habitude d'utiliser une déclaration catch générale et je traite ces exceptions de manière générale. Est-ce une mauvaise pratique ? Dans l'affirmative, comment puis-je savoir quelles exceptions spécifiques peuvent être levées et lesquelles dois-je attraper ?
Réponses
Trop de publicités?
Hamish Grubijan
Points
2078
Comme Kyle l'a dit, faites en sorte que vos méthodes soient de petite longueur, mettez des essais/attrapages autour de petites zones seulement. Passez la souris sur les méthodes que vous appelez - vous devriez alors obtenir une liste d'exceptions. Cette liste n'attrapera pas toutes les exceptions répertoriées, mais les exceptions peuvent également être découvertes de manière empirique si vous imprimez le type d'exception à l'intérieur de votre fichier catch (Exception e) { ... } . Ce que vous cherchez, c'est e.GetType().FullName y e.StackTrace y e.Message y e.InnerException ... ou un sous-ensemble de ce que j'ai énuméré.
Thibault Falise
Points
2876
Lorsque vous utilisez les méthodes du framework, vous pouvez consulter la documentation MSDN. Chaque description de méthode comporte une liste d'exceptions potentiellement déclenchées.
À titre d'exemple, consultez le paragraphe sur les exceptions dans la section Fichier.Ouvrir() documentation.
Lorsque vous utilisez votre propre méthode, vous devez être conscient des exceptions potentiellement levées par vos méthodes.
Daniel Renshaw
Points
12272
La documentation décrit souvent les exceptions qu'une méthode peut lever et les conditions dans lesquelles cela peut se produire. C'est notamment le cas de la documentation de référence de Microsoft pour le cadre .NET.
À mon avis, les exceptions ne doivent être capturées que si vous avez une bonne raison de le faire. Cela signifie généralement que les attraper et les traiter de manière générique est inutile. L'enregistrement des exceptions (une activité très courante dans un gestionnaire d'exceptions) ne devrait avoir lieu qu'au bas de la pile d'appels ou chaque fois que vous ne relancez pas l'exception (éventuellement enveloppée), ce qui devrait être rare. Si vous souhaitez qu'une action soit exécutée à chaque trame de la pile d'appels lorsqu'une exception est en cours de traitement, jetez un coup d'œil aux techniques de programmation orientée aspect (AOP).
David
Points
4672
Sauf dans de rares situations, je considère généralement les blocs catch comme une odeur de code.
Empêche les exceptions d'être levées en vérifiant les conditions au préalable. Par exemple, si vous lisez un fichier, utilisez les classes de System.IO pour vérifier si le fichier existe, plutôt que d'utiliser un bloc catch pour gérer la situation où le fichier n'existe pas.
Les blocs Catch ne doivent pas faire partie de la logique de votre application.
Damien_The_Unbeliever
Points
102139
Vous devez retenir les exceptions pour lesquelles vous pouvez élaborer une stratégie raisonnable pour traiter le problème. Il ne sert à rien d'attraper une exception s'il n'y a pas d'alternative raisonnable (réessayer plus tard, utiliser une technologie/technique différente pour atteindre le même objectif global, informer l'utilisateur que l'objectif ne peut pas être atteint actuellement et ce qu'ils peuvent faire pour remédier à la situation ).
Exception (pardon) : Il vaut la peine d'avoir quelque chose au tout premier niveau (par exemple Application.ThreadException ou AppDOmain.UnhandledException) pour tenter de consigner les exceptions que vous n'avez pas traitées. Si la journalisation échoue, vous êtes de toute façon condamné.
Mais avaler aveuglément toutes les exceptions (surtout à bas niveau) peut conduire à des séances de débogage/diagnostic très frustrantes.
