Dans quelles circonstances quelqu'un devrait-il «essayer ... attraper»? Est-ce que cela s'applique aux bibliothèques?

Question

Supposons que vous conceviez une application (WebApp, Desktop, n'importe quoi) et que vous deviez définir la gestion des exceptions pour le code. Puisque vous voulez rendre les choses réutilisables, quelle logique devriez-vous suivre lorsque vous manipulez des exceptions? Y a-t-il des modèles à suivre? Par exemple, si une DLL doit utiliser le réseau et que le réseau n'est pas fiable, il peut être judicieux de remplacer le gestionnaire d'exceptions de cette fonction pour réessayer la demande.

Comment un développeur aborde-t-il la gestion des exceptions pour tous les aspects communs du développement? Y a-t-il un modèle ou un modèle à suivre? Lorsque vous traitez des choses telles que le réseau, les fichiers, les E/S, Active Directory et le Web, je suis certain qu'il existe des pratiques exemplaires prédéfinies sur la façon de gérer les problèmes les plus courants et les plus problématiques aujourd'hui. Où sont-ils situés?

Answer 1

Lancer une exception ne doit naturellement être effectué que dans une situation exceptionnelle.

Pour la manipulation, je dirais qu'il ya deux circonstances quand vous voulez capturer une exception:

quand il y a une traduction à faire

• à un code d'erreur
• Pour une autre exception
• Pour quelque chose que l'utilisateur peut comprendre

à une limite du module

• retour de COM appelle, par exemple (dans un cadre non-aware exception)
• retour d'un fil (il n'y a personne pour prendre autrement)
• retourné à partir d'une fonction appelée-retour (car il est peu probable que le mécanisme de rappel sait ou se soucie de votre exception.)

Si vous vous trouvez faire un try-catch-nettoyage-rethrow genre de chose, utilisez RAII plutôt une d se débarrasser de l'essai ... attraper entièrement. Ecrivez votre code de sorte que, si une exception se produit, il agit de manière sensée. Recherchez les garanties Abrahams pour plus de détails sur ce que cela implique. Une réponse à MakerOfThings7 ci-dessous, parce que c'était trop long pour un commentaire.

Par "Quelque chose que l'utilisateur peut comprendre", je veux dire par exemple un message d'erreur pop-up. Imaginez, si vous voulez, que l'utilisateur clique sur un bouton de l'interface utilisateur de votre application pour aller récupérer certaines données. Votre gestionnaire de clics sur un bouton envoie vers une interface de stockage de données. Cette interface pourrait obtenir les données d'un flux de mémoire, d'un fichier, d'une base de données. Qui sait? À leur tour, ceux-ci peuvent échouer, générant une exception MemoryStreamException, une exception FileException ou une exception DatabaseException. Celles-ci ont pu être jetées 15 images de pile et ont été correctement ignorées par un code de sécurité des exceptions bien écrit qui n'a pas besoin de les traduire. Le gestionnaire de clic de bouton ne sait rien de cela, car il existe une armée croissante de méthodes de stockage de données disponibles pour l'interface de stockage de données. Ainsi, l'interface de stockage de données intercepte ces exceptions et les traduit en une exception DataStorageException à usage général. Ceci est jeté.

Ensuite, le bouton gestionnaire de clic qui a appelé l'interface de stockage de données des captures de cette exception, et a suffisamment d'informations pour pouvoir afficher une sorte de message d'erreur à l'utilisateur, traduit l'exception dans un texte bien formaté et présente il.

Answer 2

La règle générale consiste à capturer les exceptions génériques et à générer des exceptions spécifiques au domaine. Avoir également un mode de débogage pour l'API afin que vous vous connectiez à chaque exception et que vous puissiez le déboguer pour les prochaines versions.

Bien sûr, cela nécessite un bon débogage car vous ne voulez pas générer d'exceptions sans rapport.

Juste mes deux cents :).

Answer 3

D'une manière générale:

1. renverrait une exception dans des conditions exceptionnelles.

2. Gérez une exception si cela est logique. Si vous ne pouvez pas gérer l'exception, autorisez-la à migrer vers le haut de la pile d'appels.

La documentation pour les frameworks tels que .NET décrit généralement les exceptions qui peuvent être levées pour un appel de méthode particulier.

Answer 4

Vous avez répondu à votre propre question. Partout où il existe une possibilité d'erreur hors du contrôle/de la portée de votre application, il est judicieux de placer la gestion des erreurs. Vous ne pouvez jamais avoir trop de gestion des erreurs. Assurez-vous de ne pas coder par exception.

Answer 5

Les exceptions sont utiles lors du débogage. Ils devraient être évités si possible, parce que vous devriez connaître votre flux de contrôle.