Parfois, lorsque j'exécute mon application, cela me donne une erreur qui ressemble à:
Exception in thread "main" java.lang.NullPointerException
at com.example.myproject.Book.getTitle(Book.java:16)
at com.example.myproject.Author.getBookTitles(Author.java:25)
at com.example.myproject.Bootstrap.main(Bootstrap.java:14)Les gens ont appelé cela une "trace de pile". Qu'est-ce qu'une trace de pile? Que peut-il me dire sur l'erreur qui se produit dans mon programme?
À propos de cette question - très souvent, je vois une question surgir par laquelle un programmeur novice "obtient une erreur", et il colle simplement sa trace de pile et un bloc de code aléatoire sans comprendre ce qu'est la trace de pile ou comment il peut l'utiliser. Cette question est conçue comme une référence pour les programmeurs débutants qui pourraient avoir besoin d'aide pour comprendre la valeur d'une trace de pile.
java
debugging
stack-trace
Rob Hruska
la source
la source
Réponses:
En termes simples, une trace de pile est une liste des appels de méthode que l'application était au milieu lorsqu'une exception a été levée.
Exemple simple
Avec l'exemple donné dans la question, nous pouvons déterminer exactement où l'exception a été levée dans l'application. Jetons un œil à la trace de la pile:
Il s'agit d'une trace de pile très simple. Si nous commençons au début de la liste des "à ...", nous pouvons dire où s'est produite notre erreur. Ce que nous recherchons, c'est l' appel de méthode le plus haut qui fait partie de notre application. Dans ce cas, c'est:
Pour déboguer cela, nous pouvons ouvrir
Book.javaet regarder la ligne16, qui est:Cela indiquerait que quelque chose (probablement
title) se trouvenulldans le code ci-dessus.Exemple avec une chaîne d'exceptions
Parfois, les applications interceptent une exception et la rejettent comme cause d'une autre exception. Cela ressemble généralement à:
Cela pourrait vous donner une trace de pile qui ressemble à:
Ce qui est différent dans celui-ci, c'est le "Causé par". Parfois, les exceptions auront plusieurs sections "Causées par". Pour ceux-ci, vous voulez généralement trouver la «cause racine», qui sera l'une des sections «Causées par» les plus basses dans la trace de la pile. Dans notre cas, c'est:
Encore une fois, avec cette exception, nous voudrions regarder la ligne
22deBook.javapour voir ce qui pourrait provoquerNullPointerExceptionici.Exemple plus intimidant avec le code de bibliothèque
Habituellement, les traces de pile sont beaucoup plus complexes que les deux exemples ci-dessus. Voici un exemple (il est long, mais montre plusieurs niveaux d'exceptions chaînées):
Dans cet exemple, il y en a beaucoup plus. Ce qui nous préoccupe le plus, c'est la recherche de méthodes qui proviennent de notre code , qui seraient n'importe quoi dans le
com.example.myprojectpackage. Dans le deuxième exemple (ci-dessus), nous voudrions d'abord regarder vers le bas pour la cause racine, qui est:Cependant, tous les appels de méthode sous ce code sont de la bibliothèque. Nous allons donc passer au "Causé par" au-dessus, et chercher le premier appel de méthode provenant de notre code, qui est:
Comme dans les exemples précédents, nous devrions regarder en
MyEntityService.javaligne59, car c'est de là que cette erreur est originaire (celle-ci est un peu évidente ce qui s'est mal passé, car la SQLException indique l'erreur, mais la procédure de débogage est ce que nous recherchons).la source
Exception in thread "main"dans votre premier exemple. Je pense qu'il serait particulièrement utile d'expliquer que cette ligne est souvent accompagnée d'un message, comme la valeur d'une variable, qui peut aider à diagnostiquer le problème. J'ai essayé de faire une modification moi-même, mais j'ai du mal à intégrer ces idées dans la structure existante de votre réponse.Je poste cette réponse, donc la réponse la plus élevée (lorsqu'elle est triée par activité) n'est pas celle qui est tout simplement fausse.
Qu'est-ce qu'un Stacktrace?
Un stacktrace est un outil de débogage très utile. Il montre la pile d'appels (c'est-à-dire la pile de fonctions qui ont été appelées jusqu'à ce point) au moment où une exception non interceptée a été levée (ou au moment où la trace de pile a été générée manuellement). Ceci est très utile car il vous montre non seulement où l'erreur s'est produite, mais aussi comment le programme s'est retrouvé à cet endroit du code. Cela nous amène à la question suivante:
Qu'est-ce qu'une exception?
Une exception est ce que l'environnement d'exécution utilise pour vous indiquer qu'une erreur s'est produite. Des exemples populaires sont NullPointerException, IndexOutOfBoundsException ou ArithmeticException. Chacun de ces problèmes survient lorsque vous essayez de faire quelque chose qui n'est pas possible. Par exemple, une NullPointerException sera levée lorsque vous essayez de déréférencer un objet Null:
Comment dois-je gérer les Stacktraces / Exceptions?
Dans un premier temps, découvrez ce qui cause l'exception. Essayez de rechercher sur Google le nom de l'exception pour savoir quelle est la cause de cette exception. La plupart du temps, cela sera dû à un code incorrect. Dans les exemples ci-dessus, toutes les exceptions sont causées par un code incorrect. Donc, pour l'exemple NullPointerException, vous pouvez vous assurer que ce
an'est jamais nul à ce moment-là. Vous pouvez, par exemple, initialiseraou inclure un chèque comme celui-ci:De cette façon, la ligne incriminée n'est pas exécutée si
a==null. Il en va de même pour les autres exemples.Parfois, vous ne pouvez pas vous assurer de ne pas obtenir d'exception. Par exemple, si vous utilisez une connexion réseau dans votre programme, vous ne pouvez pas empêcher l'ordinateur de perdre sa connexion Internet (par exemple, vous ne pouvez pas empêcher l'utilisateur de déconnecter la connexion réseau de l'ordinateur). Dans ce cas, la bibliothèque réseau lèvera probablement une exception. Vous devez maintenant intercepter l'exception et la gérer . Cela signifie que, dans l'exemple avec la connexion réseau, vous devez essayer de rouvrir la connexion ou avertir l'utilisateur ou quelque chose comme ça. De plus, chaque fois que vous utilisez catch, n'attrapez toujours que l'exception que vous souhaitez intercepter, n'utilisez pas de déclarations catch larges comme
catch (Exception e)cela intercepterait toutes les exceptions. Ceci est très important, car sinon vous pourriez accidentellement attraper la mauvaise exception et réagir de la mauvaise manière.Pourquoi ne devrais-je pas utiliser
catch (Exception e)?Prenons un petit exemple pour montrer pourquoi vous ne devriez pas simplement intercepter toutes les exceptions:
Ce que ce code essaie de faire est d'attraper le
ArithmeticExceptioncausé par une division possible par 0. Mais il attrape également un possibleNullPointerExceptionqui est levé siaoubsontnull. Cela signifie que vous pourriez en avoir unNullPointerExceptionmais vous le traiterez comme une ArithmeticException et vous ferez probablement la mauvaise chose. Dans le meilleur des cas, il vous manque toujours une exception NullPointerException. Des trucs comme ça rendent le débogage beaucoup plus difficile, alors ne faites pas ça.TLDR
Si 1. n'est pas possible, interceptez l'exception spécifique et gérez-la.
catch (Exception e), toujours attraper des exceptions spécifiques. Cela vous évitera beaucoup de maux de tête.la source
Pour ajouter à ce que Rob a mentionné. La définition de points d'arrêt dans votre application permet le traitement pas à pas de la pile. Cela permet au développeur d'utiliser le débogueur pour voir à quel point exact la méthode fait quelque chose d'imprévu.
Étant donné que Rob a utilisé le
NullPointerException(NPE) pour illustrer quelque chose de commun, nous pouvons vous aider à supprimer ce problème de la manière suivante:si nous avons une méthode qui prend des paramètres tels que:
void (String firstName)Dans notre code, nous voudrions évaluer qui
firstNamecontient une valeur, nous le ferions comme ceci:if(firstName == null || firstName.equals("")) return;Ce qui précède nous empêche d'utiliser
firstNamecomme paramètre dangereux. Par conséquent, en effectuant des vérifications nulles avant le traitement, nous pouvons nous assurer que notre code fonctionnera correctement. Pour développer un exemple qui utilise un objet avec des méthodes, nous pouvons regarder ici:if(dog == null || dog.firstName == null) return;Ce qui précède est l'ordre approprié pour vérifier les valeurs nulles, nous commençons par l'objet de base, chien dans ce cas, puis commençons à descendre l'arborescence des possibilités pour nous assurer que tout est valide avant le traitement. Si l'ordre était inversé, un NPE pourrait potentiellement être lancé et notre programme se bloquerait.
la source
nullquand unNullPointerExceptionest en cours d'examen, par exemple.La famille Throwable offre une autre fonctionnalité de trace de pile : la possibilité de manipuler les informations de trace de pile.
Comportement standard:
Trace de la pile:
Trace de pile manipulée:
Trace de la pile:
la source
Pour comprendre le nom : Une trace de pile est une liste d'exceptions (ou vous pouvez dire une liste de "cause par"), de l'exception la plus superficielle (par exemple, exception de couche de service) à la plus profonde (par exemple exception de base de données). Tout comme la raison pour laquelle nous l'appelons `` pile '' est parce que la pile est First in Last out (FILO), l'exception la plus profonde s'est produite au tout début, puis une chaîne d'exceptions a été générée une série de conséquences, l'exception de surface était la dernière on est arrivé à temps, mais on le voit en premier lieu.
Clé 1 : Une chose délicate et importante ici doit être comprise: la cause la plus profonde peut ne pas être la "cause racine", car si vous écrivez du "mauvais code", cela peut provoquer une exception en dessous qui est plus profonde que sa couche. Par exemple, une mauvaise requête SQL peut entraîner une réinitialisation de la connexion SQLServerException dans le bottem au lieu d'une erreur syndax, qui peut se trouver juste au milieu de la pile.
-> Localiser la cause première au milieu est votre travail.
Clé 2 : Une autre chose délicate mais importante est à l'intérieur de chaque bloc "Cause par", la première ligne était la couche la plus profonde et arrive en première place pour ce bloc. Par exemple,
Book.java:16 a été appelé par Auther.java:25 qui a été appelé par Bootstrap.java:14, Book.java:16 en était la cause première. Ci-joint un diagramme qui trie la pile de trace dans l'ordre chronologique.
la source
Juste pour ajouter aux autres exemples, il existe des classes internes (imbriquées) qui apparaissent avec le
$signe. Par exemple:Entraînera cette trace de pile:
la source
Les autres articles décrivent ce qu'est une trace de pile, mais il peut toujours être difficile de travailler avec.
Si vous obtenez une trace de pile et souhaitez rechercher la cause de l'exception, un bon point de départ pour la comprendre est d'utiliser la console de trace de pile Java dans Eclipse . Si vous utilisez un autre IDE, il peut y avoir une fonctionnalité similaire, mais cette réponse concerne Eclipse.
Tout d'abord, assurez-vous que toutes vos sources Java sont accessibles dans un projet Eclipse.
Ensuite, dans la perspective Java , cliquez sur l' onglet Console (généralement en bas). Si la vue de la console n'est pas visible, accédez à l'option de menu Fenêtre -> Afficher la vue et sélectionnez Console .
Puis dans la fenêtre de la console, cliquez sur le bouton suivant (à droite)
puis sélectionnez Java Stack Trace Console dans la liste déroulante.
Collez votre trace de pile dans la console. Il fournira ensuite une liste de liens vers votre code source et tout autre code source disponible.
Voici ce que vous pourriez voir (image de la documentation Eclipse):
L'appel de méthode le plus récent sera le haut de la pile, qui est la première ligne (à l'exclusion du texte du message). Descendre la pile remonte dans le temps. La deuxième ligne est la méthode qui appelle la première ligne, etc.
Si vous utilisez un logiciel open source, vous devrez peut-être télécharger et joindre à votre projet les sources si vous souhaitez les examiner. Téléchargez les fichiers source, dans votre projet, ouvrez le dossier Bibliothèques référencées pour trouver votre fichier pour votre module open-source (celui avec les fichiers de classe) puis cliquez avec le bouton droit, sélectionnez Propriétés et attachez le fichier source.
la source