Une exception est une erreur de blocage .
Tout d'abord, la meilleure pratique devrait être de ne pas lever d'exceptions pour tout type d'erreur, sauf s'il s'agit d'une erreur de blocage .
Si l'erreur est bloquante , lancez l'exception. Une fois que l'exception est déjà levée, il n'est pas nécessaire de la cacher car elle est exceptionnelle; faites-le savoir à l'utilisateur (vous devez reformater toute l'exception en quelque chose d'utile pour l'utilisateur dans l'interface utilisateur).
Votre travail en tant que développeur de logiciels consiste à éviter un cas exceptionnel où certains paramètres ou situations d'exécution peuvent se terminer par une exception. Autrement dit, les exceptions ne doivent pas être mises en sourdine, mais elles doivent être évitées .
Par exemple, si vous savez qu'une entrée entière peut avoir un format non valide, utilisez int.TryParse
plutôt que int.Parse
. Il y a beaucoup de cas où vous pouvez le faire au lieu de simplement dire "si cela échoue, jetez simplement une exception".
Lancer des exceptions coûte cher.
Si, après tout, une exception est levée, au lieu d'écrire l'exception dans le journal une fois qu'elle a été levée, l'une des meilleures pratiques consiste à l'attraper dans un gestionnaire d'exceptions de première chance . Par exemple:
- ASP.NET: Global.asax Application_Error
- Autres: événement AppDomain.FirstChanceException .
Ma position est que les tentatives / captures locales sont mieux adaptées pour gérer des cas spéciaux où vous pouvez traduire une exception en une autre, ou lorsque vous voulez la "couper" pour un cas très, très, très, très, très spécial (un bug de bibliothèque levant une exception sans rapport que vous devez désactiver pour contourner tout le bogue).
Pour le reste des cas:
- Essayez d'éviter les exceptions.
- Si ce n'est pas possible: gestionnaires d'exceptions de première chance.
- Ou utilisez un aspect PostSharp (AOP).
Répondre à @thewhiteambit sur un commentaire ...
@thewhiteambit a déclaré:
Les exceptions ne sont pas des erreurs fatales, ce sont des exceptions! Parfois, ce ne sont même pas des erreurs, mais les considérer comme des erreurs fatales est une compréhension complètement fausse de ce que sont les exceptions.
Tout d'abord, comment une exception ne peut-elle même pas être une erreur?
- Aucune connexion à la base de données => exception.
- Format de chaîne non valide pour analyser une exception de type =>
- Essayer d'analyser JSON et alors que l'entrée n'est pas en fait JSON => exception
- Argument
null
alors que l'objet était attendu => exception
- Certaines bibliothèques ont un bug => lève une exception inattendue
- Il y a une connexion socket et elle est déconnectée. Ensuite, vous essayez d'envoyer un message => exception
- ...
Nous pourrions énumérer 1k cas où une exception est levée, et après tout, l'un des cas possibles sera une erreur .
Une exception est une erreur, car à la fin de la journée, c'est un objet qui collecte des informations de diagnostic - il a un message et cela se produit lorsque quelque chose ne va pas.
Personne ne lèverait une exception lorsqu'il n'y a pas de cas exceptionnel. Les exceptions devraient bloquer les erreurs, car une fois qu'elles sont levées, si vous n'essayez pas de tomber dans l' utilisation try / catch et les exceptions pour implémenter le flux de contrôle, cela signifie que votre application / service arrêtera l'opération qui est entrée dans un cas exceptionnel .
Aussi, je suggère à tout le monde de vérifier le paradigme fail-fast publié par Martin Fowler (et écrit par Jim Shore) . C'est ainsi que j'ai toujours compris comment gérer les exceptions, même avant d'arriver à ce document il y a quelque temps.
[...] les considérer comme des erreurs fatales est une compréhension complètement fausse de ce que sont les exceptions.
Habituellement, les exceptions réduisent certains flux d'opérations et sont traitées pour les convertir en erreurs compréhensibles par l'homme. Ainsi, il semble qu'une exception soit en fait un meilleur paradigme pour gérer les cas d'erreur et y travailler pour éviter un plantage complet de l'application / service et informer l'utilisateur / consommateur que quelque chose s'est mal passé.
Plus de réponses sur @thewhiteambit
Par exemple, en cas de connexion à une base de données manquante, le programme peut exceptionnellement continuer à écrire dans un fichier local et envoyer les modifications à la base de données une fois qu'elle est à nouveau disponible. Votre transtypage String-to-Number invalide pourrait être essayé à nouveau d'analyser avec une interprétation locale de la langue sur Exception, comme lorsque vous essayez la langue anglaise par défaut pour analyser ("1,5") échoue et vous essayez à nouveau avec une interprétation allemande qui est complètement bien parce que nous utilisons une virgule au lieu du point comme séparateur. Vous voyez que ces exceptions ne doivent même pas être bloquantes, elles ont seulement besoin d'une gestion des exceptions.
Si votre application peut fonctionner hors ligne sans conserver les données dans la base de données, vous ne devez pas utiliser d' exceptions , car l'implémentation du flux de contrôle à l'aide try/catch
est considérée comme un anti-modèle. Le travail hors ligne est un cas d'utilisation possible, vous implémentez donc un flux de contrôle pour vérifier si la base de données est accessible ou non, vous n'attendez pas qu'elle soit inaccessible .
L' analyse est également un cas attendu ( pas un CAS EXCEPTIONNEL ). Si vous vous y attendez, vous n'utilisez pas d'exceptions pour contrôler le flux! . Vous obtenez des métadonnées de l'utilisateur pour savoir quelle est sa culture et vous utilisez des formateurs pour cela! .NET prend également en charge cet environnement et d'autres, et une exception car la mise en forme des nombres doit être évitée si vous vous attendez à une utilisation spécifique à la culture de votre application / service .
Une exception non gérée devient généralement une erreur, mais les exceptions elles-mêmes ne sont pas codeproject.com/Articles/15921/Not-All-Exceptions-Are-Errors
Cet article n'est qu'un avis ou un point de vue de l'auteur.
Étant donné que Wikipédia peut également être uniquement l'opinion des auteurs d'articules, je ne dirais pas que c'est le dogme , mais vérifiez ce que l'article Codage par exception dit quelque part dans un paragraphe:
[...] L'utilisation de ces exceptions pour gérer des erreurs spécifiques qui surviennent pour continuer le programme est appelée codage par exception. Cet anti-modèle peut rapidement dégrader les performances et la maintenabilité du logiciel.
Cela dit aussi quelque part:
Utilisation d'exception incorrecte
Souvent, le codage par exception peut entraîner d'autres problèmes dans le logiciel avec une utilisation d'exception incorrecte. En plus d'utiliser la gestion des exceptions pour un problème unique, une utilisation incorrecte des exceptions va plus loin en exécutant du code même après le déclenchement de l'exception. Cette mauvaise méthode de programmation ressemble à la méthode goto dans de nombreux langages logiciels mais ne se produit qu'après détection d'un problème dans le logiciel.
Honnêtement, je crois qu'un logiciel ne peut pas être développé sans prendre au sérieux les cas d'utilisation. Si tu le sais ...
- Votre base de données peut se déconnecter ...
- Certains fichiers peuvent être verrouillés ...
- Certains formats peuvent ne pas être pris en charge ...
- Une validation de domaine peut échouer ...
- Votre application devrait fonctionner en mode hors ligne ...
- quel que soit le cas d'utilisation ...
... vous n'utiliserez pas d'exceptions pour cela . Vous prendriez en charge ces cas d'utilisation à l'aide d'un flux de contrôle régulier.
Et si un cas d'utilisation inattendu n'est pas couvert, votre code échouera rapidement, car il lèvera une exception . D'accord, car une exception est un cas exceptionnel .
D'autre part, et enfin, parfois, vous couvrez des cas exceptionnels en lançant des exceptions attendues , mais vous ne les lancez pas pour implémenter le flux de contrôle. Vous le faites parce que vous souhaitez informer les couches supérieures que vous ne prenez pas en charge certains cas d'utilisation ou que votre code ne fonctionne pas avec certains arguments ou données / propriétés d'environnement donnés.