2012-11-28 2 views
8

Lorsqu'une exception non interceptée est lancée dans mon code, je suis habitué à ce que le débogueur s'arrête à l'instruction throw afin que je puisse examiner les variables locales et les membres de tous les objets impliqués dans le moment où l'exception a été levée. Avec IntelliJ Idea cela peut être accompli en allant Run, Voir les points d'arrêt, en sélectionnant l'Exception des points d'arrêt onglet, vérification Toute exception, et faire en sorte que la exception Caught case est cochée, alors que la L'exception non interceptée est cochée. Avec Eclipse et avec Visual Studio (pour C#) c'est quelque chose de différent, mais dans le même sens.JUnit 4 et Suspend-on-Exception

La possibilité de faire que le débogueur se comporte de cette manière est extrêmement utile; si utile en fait, que je structure la boucle principale de mes programmes en conséquence: sur la version release, la boucle principale est bien sûr embarquée dans un try-catch-all; mais sur la version de débogage, il n'y a pas de bloc try-catch dans la boucle principale, de sorte que les exceptions qui ne sont pas interceptées dans mon programme resteront inchangées, de sorte que le débogueur suspendra mon programme au moment où elles sont lancées.

Lors du test de mes classes Java avec JUnit, cependant, j'ai un problème: le débogueur ne s'arrête à aucune exception. Au lieu de cela, ce qui se passe est que non seulement les exceptions inattendues, mais aussi inattendues, sont automagiquement interceptées, et on me donne une trace de pile d'exceptions post-mortem pour essayer de donner un sens. Ce n'est pas très cool.

Je pensais que cela se produit parce que JUnit utilise java.lang.reflect.Method.invoke(), qui capture toutes les exceptions et les transforme en TargetInvocationExceptions, mais j'ai écrit mon propre coureur JUnit personnalisé, qui connaît ma classe de test personnellement et directement invoque ses méthodes sans Method.invoke(), et le problème persiste. Cela signifie que le problème se situe très haut dans le noyau JUnit.

Alors, quelqu'un d'autre a-t-il le même problème? Est-ce que quelqu'un connaît une solution pour que le débogueur puisse suspendre l'exécution du programme sur des exceptions inattendues lors de tests avec JUnit?

connexes (sans réponse) Question: Suspend on uncaught runtime exceptions in Eclipse Junit test runner

connexes (sans réponse) Question: How to break into debugger within a jUnit test case?

connexes (réponse partielle) Question: Break on Exception in Eclipse using jUnit (La réponse acceptée dit que « si vous déboguer une seule méthode dans JUnit, Si une classe entière ou un paquet est débogué dans jUnit, le débogueur ne fonctionne pas. ")

+0

Quelle version de JUnit exécutez-vous? Je peux attraper des exceptions non interceptées dans mes tests très bien, Eclipse Indigo Build 20110615-0604, JUnit 4. – Perception

+2

J'utilise JUnit 4.8.1. Veuillez noter que cette question ne concerne pas les exceptions non interceptées; Il s'agit de faire en sorte que le débogueur suspende l'exécution du programme sur les exceptions non interceptées. En d'autres termes, il s'agit de faire en sorte que l'instruction 'throw' se comporte comme un point d'arrêt si l'exception lancée est non interceptée. –

+0

Je suppose que je n'étais pas clair. Mon IDE (Eclipse Indigo), suspend l'exécution automatiquement, si je le dis aussi, sur les exceptions captées/non interceptées. Même lors de l'exécution d'un test JUnit 4. – Perception

Répondre

0

Pour contourner ce problème, vous pouvez créer une instance du test incriminé classe dans la méthode principale et appel sa méthode de test à la main avec votre méthode de points d'exception (qui est très sympa en passant, merci pour la question). De cette façon, la méthode n'est pas appelée de manière réfléchie.

+2

Merci pour la réponse, mais comme vous le dites, ce n'est pas une vraie solution, c'est une solution de contournement. En fait, il est plus facile de simplement aller à la ligne où l'exception a été lancée, (en cliquant sur la trace de la pile,) placez un point d'arrêt là, et relancez. Je veux juste éviter d'avoir à faire ça. –

1

J'espère que je comprends bien la question, corrigez-moi si je me trompe, mais:

  • vous avez un test, ce qui jette une exception, que vous ne vous surprenez pas (il en ce sens, est uncaught)
  • lors du débogage ce test avec le TestRunner junit4, JUnit vous montre que le test échoue (il a lancé l'exception)
  • mais le fil ne soit pas suspendu, ce qui est ce que vous voulez atteindre
  • même si preferences | java | debug | suspend execution on uncaught exceptions est activé

Dans ce cas, je crois que c'est le comportement prévu, les prises de JUnit et engloutit votre exception, il est donc pas non attrapée en ce qui éclipse concerne, comme décrit ici https://bugs.eclipse.org/bugs/show_bug.cgi?id=414133

Vous pouvez avoir eclipse suspendent de toute façon en mettant en place vos propres règles pour suspendre sur les exceptions interceptées. Debug perspective | breakpoint view | J! icon | check suspend on caught exception

+0

Votre compréhension de la question est correcte. Cependant, votre solution proposée ne fonctionnera pas, car des milliers d'exceptions (qui sont interceptées) sont lancées, à la fois dans du code sur lequel je n'ai aucun contrôle et dans mon code sous des opérations normales, ainsi que dans mon code pour tester le vérification d'erreur et le code de manipulation. –

+0

Je ne peux même pas utiliser les filtres de classe pour au moins prendre en charge les exceptions levées et interceptées par le Java Runtime, car parfois les exceptions lancées par le Java Runtime se propagent à mon code, et je voudrais que le débogueur Le code invoque la méthode d'exécution qui a été lancée, mais les débogueurs Java n'ont apparemment aucune notion de "rupture dans mon code uniquement" comme le fait Microsoft Visual Studio. –

+0

Ah oui, je comprends, et vu le lien que j'ai posté je suppose que votre dernière phrase est correcte, le débogueur eclipse ne semble pas avoir une notion de suspension seulement dans votre code. Cela semble laisser JUnit ne pas avaler vos exceptions comme votre seule option ... Je ne sais pas si c'est possible ... – Hirle