Comment implémenter la gestion des exceptions de premier niveau?

Question

J'ai récemment dû développer un module supplémentaire pour un service existant développé par un collègue. Il avait placé un bloc try / catch dans la fonction de travail principale pour capturer toutes les exceptions non masquées qui remontaient à ce niveau, en les consignant avec les informations de trace de pile, etc.:

try
{
    // do main work
}
catch(Exception ex)
{
    // log exception info
}

Bien que cela rend le programme très stable (comme dans "peu de chances de planter"), je le déteste parce que, lorsque je teste mon code, je ne vois pas les exceptions causées par celui-ci. Bien sûr, je peux regarder le journal des exceptions et voir s’il ya de nouvelles entrées, mais je préfère de loin le retour direct de l’exception au moment où elle est levée (avec le curseur sur la ligne droite du code, s’il vous plaît).

J'ai enlevé ce niveau supérieur d'essayer / attraper au moins alors que j'étais encore en train de coder et de tester. Mais maintenant ma tâche est terminée et je dois décider de la remettre ou non pour la publication. Je pense que je devrais le faire, car cela rend le service plus stable et l’essentiel est qu’il fonctionne en arrière-plan sans nécessiter de supervision. Par contre, j’ai lu qu’il ne fallait appeler que des exceptions spécifiques (comme dans IoException ), et non de manière générique Exception .

Quel est votre avis sur cette question?

Au fait, le projet est écrit en C #, mais je suis également intéressé par les réponses pour les langages non .NET.

Answer 1

Remettez-le.

L'exception ne devrait être pertinente que lors des tests. Sinon, cela n'a pas de sens de le faire apparaître à l'utilisateur.

L’enregistrement se passe bien.

Vous pouvez également utiliser le symbole DEBUG défini par Visual Studio pour les générations de débogage en tant qu'indicateur.

    ...
    } catch( Exception e ) { 
#if DEBUG
          throw;
#else
          log as usual 
#endif
    }

Ainsi, la prochaine fois qu'une modification est nécessaire, l'indicateur de débogage doit être défini sur true et l'exception apparaîtra.

Answer 2

Dans toutes les applications Java, vous voulez toujours définir un gestionnaire d'exceptions pour les exceptions non capturées, avec quelque chose comme ceci:

Thread.setDefaultUncaughtExceptionHandler( ... );

où l'objet qui interceptera ces exceptions non capturées enregistrera au moins l'échec afin que vous ayez une chance de le savoir. Sinon, rien ne garantit que vous serez même averti qu'un thread a pris une exception - sauf si c'est votre thread principal.

En plus de cela, la plupart de mes threads ont un essai / attrape où je vais attraper RunnableException (mais pas Erreur ) et le consigner ... certains Les threads mourront lorsque cela se produira, d'autres se connecteront et ignoreront, d'autres afficheront une plainte auprès de l'utilisateur et lui laisseront le choix, en fonction des besoins de l'application. Cet try / catch est à la racine même du Thread, dans la méthode Runnable.run () ou son équivalent. Puisque try / catch est à la racine du Thread, il n’est pas nécessaire de désactiver parfois cette capture.

Lorsque j'écris en C #, je code de la même manière. Mais tout dépend du besoin de l'application. L'exception est-elle celle qui corrompra les données? Bien alors, ne l'attrape pas et l'ignore. TOUJOURS le consigner, mais ensuite, laissez l’application mourir. La plupart des exceptions ne sont toutefois pas de ce type.

Answer 3

Idéalement, vous souhaitez gérer une exception aussi près que possible de son origine, mais cela ne signifie pas qu'un gestionnaire d'exception global est une mauvaise idée. Surtout pour un service qui doit rester actif à tout prix. Je voudrais continuer ce que vous avez fait. Désactivez-le pendant le débogage mais laissez-le en place pour la production.

N'oubliez pas qu'il doit être utilisé comme filet de sécurité. Essayez toujours d’attraper toutes les exceptions avant d’élever aussi loin.

Answer 4

L'envie de détecter toutes les exceptions et de rendre le programme "stable" est très forte et l'idée semble séduisante pour tout le monde. Le problème que vous soulignez est qu’il s’agit simplement d’une ruse et que le programme peut très bien être bogué et pire, sans indication d’échec. Personne ne surveille les journaux régulièrement.
Mon conseil serait d’essayer de convaincre l’autre développeur de faire des tests approfondis, puis de le déployer en production sans la prise externe.

Answer 5

Si vous voulez voir l'exception quand elle se produit, dans Visual Studio, vous pouvez aller dans le menu DEBUG, sélectionnez EXCEPTIONS et vous pouvez indiquer au débogueur de rompre dès qu'une exception est levée. Vous pouvez même choisir quel type d'exceptions. :)