Des exceptions si un programme ne jamais tenter de récupérer à partir de?

Question

Des Exceptions peuvent avoir différents degrés d'impact sur un programme. Par exemple, un programme devrait probablement abandonner en cas d' OutOfMemoryException est relevé, mais il est possible en toute sécurité et de manière appropriée poignée System.Data.SqlClient.SqlException sans mettre le programme dans un état inconnu.

Je comprends que toute exception a la possibilité de mettre le programme dans un état instable si elle n'est pas traitée correctement. Sont là des exceptions qui ne devraient jamais être manipulés au-delà de simplement la journalisation et de le jeter en haut de la pile?

Answer 1

C'est un cas-par-cas théorique de la question, la réponse sera tout aussi théorique. La meilleure réponse que j'ai jamais entendu est, "Ne pas traiter une exception si vous ne savez pas comment le gérer." L'enregistrement d'un message et en jetant l'exception de la pile est bien parce que vous avez réellement fait quelque chose (même si c'est juste indiquant qu'une erreur s'est produite). Mais, de l'interception d'une erreur et de ne pas jeter la pile peut entraîner caché bugs et difficile sessions de débogage.

Ce que nous avons toujours fait est de mettre en œuvre une erreur de niveau supérieur gestionnaire effectuer générique de gestion des erreurs (comme l'enregistrement d'un message, d'alerter les développeurs, etc.). Toutes les exceptions non gérées plus loin dans le code sont au moins traitées par le haut-gestionnaire de niveau. Les exceptions qui peuvent être traitées plus bas dans le code sont certainement manipulés où ils se produisent.

Considérons le cas d'une boucle sur une liste d'adresses e-mail pour envoyer un message à une liste de diffusion. Une exception peut se produire si l'une des adresses e-mail n'est pas correctement formaté, mais nous ne voulons pas d'une seule adresse de courriel pour entraîner le reste du traitement à l'échec. Par la manipulation de l'exception spécifique type qui se produit, nous pouvons nous connecter (ou même la marque de l'adresse e-mail invalide) et poursuivre le traitement du reste de la liste.

Bottom Line: Si vous avez ou non traiter une exception de type dépend vraiment de si oui ou non votre code ne sait plus quoi faire pour récupérer le type d'exception se produit.

Answer 2

Le Cadre des lignes Directrices de Conception de couvrir ce assez complètement:

Ne pas attraper Système.Exception ou d'un Système.SystemException dans le cadre code, sauf si vous avez l'intention de re-jeter.

...

Ne pas attraper Système.StackOverflowException.

Il est extrêmement difficile à gérer par programmation un débordement de pile. Vous devez autoriser cette exception, pour mettre fin au processus et à l'utilisation débogage pour déterminer la source du problème.

...

Ne pas attraper Système.Moment de l'exécution.InteropServices.SEHException explicitement.

Answer 3

C'est probablement un scénario différent, mais toutes les exceptions qui implique un programmeur d'erreur: NullReferenceException, IndexOutOfRangeException, etc. Cela signifie que vous avez un bug dans votre code et vous devez le réparer plutôt que de la traiter.

Answer 4

C'est très dépendante de votre application. La plupart des applications devrait probablement voir un message d'erreur et mourir pour OutOfMemoryException, mais pas tous, par exemple, a un programme appelé SmartRAM (je pense que c'est le nom) qui permet de récupérer de la RAM en essayant d'allouer plus de mémoire jusqu'à ce qu'il obtient de cette exception - cela provoque de Windows pour supprimer tous les cache dans la mémoire RAM, vous donnant plus d'espace mémoire.

Donc, cela dépend vraiment de ce que vous faites. Si vous, en tant qu'expert sur votre demande, de se sentir comme vous pouvez le récupérer en toute sécurité, de l'exception, alors vous devriez.

Answer 5

Typique exception des hiérarchies ont deux branches principales, d'exécution et de la logique des erreurs. Les anciens peuvent apparaître à tout moment, et le programme n'a que très rarement une idée raisonnable de la façon de récupérer, ce dernier est une condition d'erreur qui doit être anticipé et géré.

Java rend cette distinction explicite avec la mise en œuvre de checked exceptions; c'est une erreur si aucune exception n'est pas gérée ou déclarée comme une exception éventuelle sortie de la méthode, cependant rien descendu de l' RuntimeException est implicitement d'accord.

Si votre programme est compartimenté de manière appropriée et le cas d'utilisation le permet, vous pouvez prendre certaines exceptions d'exécution et fermer le compartiment où l'exception est originaire, mais qui n'est utile que dans des cas particuliers.

Bien que ce soit activement appliquées seulement en Java, le concept peut être appliqué ici ainsi:

• L'échec d'analyser les données d'entrée est une exception qui peut être facilement manipulé, il apparaît clairement que l'état du programme est lorsque l'exception est levée, de sorte que le nettoyage est facile (continuer avec la prochaine entrée).
• La récupération à partir d'un état de la mémoire est plus difficile parce que vous pouvez avoir besoin de supprimer le fichier de sortie si l'erreur s'est produite lors de l'écriture, sinon vous vous retrouvez avec des données partielles.
• Si votre programme accède à la mémoire invalide, vous ne devriez pas tenter de récupérer parce que vous pourriez avoir écrasé quelque chose d'autre est déjà (après tout, votre programme ne semble pas savoir où ses données), et il n'y a aucune garantie que cela fonctionnera correctement plus.