Qu'est-ce qu'une trace de pile et comment puis-je l'utiliser pour déboguer les erreurs de mon application?

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 l'heure à laquelle la stacktrace a été générée manuellement). Ceci est très utile car il ne vous montre pas seulement où l'erreur s'est produite, mais aussi comment le programme s'est retrouvé à cet endroit du code. Cela conduit à la question suivante:

Qu'est-ce qu'une exception?

Une Exception est ce que l'environnement d'exécution utilise pour vous dire qu'une erreur s'est produite. Des exemples populaires sont NullPointerException, IndexOutOfBoundsException ou ArithmeticException. Chacun d'entre eux sont causés 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 Null-objet:

Object a = null;
a.toString();                 //this line throws a NullPointerException

Object[] b = new Object[5];
System.out.println(b[10]);    //this line throws an IndexOutOfBoundsException,
                              //because b is only 5 elements long
int ia = 5;
int ib = 0;
ia = ia/ib;                   //this line throws an  ArithmeticException with the 
                              //message "/ by 0", because you are trying to
                              //divide by 0, which is not possible.

Comment dois-je gérer les Stacktraces/Exceptions?

Dans un premier temps, découvrez ce qui cause l'exception. Essayez googleing le nom de l'exception pour savoir, quelle est la cause de cette exception. La plupart du temps, il sera causé par un code incorrect. Dans les exemples donnés ci-dessus, toutes les exceptions sont causées par un code incorrect. Donc, pour l'exemple NullPointerException, vous pouvez vous assurer que a n'est jamais nul à ce moment-là. Vous pourriez, par exemple, initialisez a ou incluez une vérification comme celle-ci:

if (a!=null) {
    a.toString();
}

De Cette façon, la ligne incriminée n'est pas exécutée si a==null. En va de même pour les autres exemples.

Parfois, vous ne pouvez pas vous assurer que vous n'obtenez pas 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 jettera probablement une exception. Maintenant, vous devriez attraper l'exception et gérer . Cela signifie que, dans l'exemple avec la connexion réseau, vous devez essayer de rouvrir la connexion ou d'informer l'utilisateur ou quelque chose comme ça. De plus, chaque fois que vous utilisez catch, n'attrapez toujours que l'exception que vous souhaitez attraper, n'utilisez pas d'instructions catch larges comme catch (Exception e) cela attraperait toutes les exceptions. Ceci est très important, car sinon vous risquez d'attraper accidentellement la mauvaise exception et de réagir dans le mauvais sens.

try {
    Socket x = new Socket("1.1.1.1", 6789);
    x.getInputStream().read()
} catch (IOException e) {
    System.err.println("Connection could not be established, please try again later!")
}

Pourquoi devrais-je pas utiliser catch (Exception e)?

Utilisons un petit exemple pour montrer pourquoi vous ne devriez pas simplement attraper toutes les exceptions:

int mult(Integer a,Integer b) {
    try {
        int result = a/b
        return result;
    } catch (Exception e) {
        System.err.println("Error: Division by zero!");
        return 0;
    }
}

Ce que ce code essaie de faire est d'attraper le ArithmeticException causé par une division possible par 0. Mais il attrape également un NullPointerException possible qui est lancé si a ou b sont null. Cela signifie que vous pourriez obtenir un NullPointerException mais vous le traiterez comme une exception ArithmeticException et ferez probablement la mauvaise chose. Dans le dans le meilleur des cas, vous manquez toujours qu'il y avait une NullPointerException. Des choses comme ça rendent le débogage beaucoup plus difficile, alors ne faites pas ça.

TLDR

1. Déterminez quelle est la cause de l'exception et corrigez-la, de sorte qu'elle ne lève pas du tout l'exception.

2. Si 1. n'est pas possible, attrapez l'exception spécifique et gérez-la.

   • N'ajoutez jamais simplement un try/catch et ignorez simplement l'exception! Ne le faites pas!
   • ne Jamais utiliser catch (Exception e), toujours attraper des exceptions spécifiques. Cela vous évitera beaucoup de maux de tête.

Pour ajouter à ce que Rob a mentionné. La définition de points d'arrêt dans votre application permet le traitement étape par étape de la pile. Cela permet au développeur d'utiliser le débogueur pour voir à quel point exact la méthode fait quelque chose qui était imprévu.

Puisque Rob a utilisé le NullPointerException (NPE) pour illustrer quelque chose de commun, nous pouvons 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 voulons évaluer firstName contient une valeur, nous voudrions le faire comme ceci: if(firstName == null || firstName.equals("")) return;

Ce qui précède nous empêche d'utiliser firstName comme paramètre dangereux. Par conséquent, en effectuant des vérifications null avant le traitement, nous pouvons vous aider à vous 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 le bon ordre pour vérifier les valeurs nulles, nous commençons par l'objet de base, dog dans ce cas, puis commençons marcher dans l'arbre des possibilités pour s'assurer que tout est valide avant le traitement. Si l'ordre était inversé, un NPE pourrait potentiellement être lancé et notre programme se bloquerait.

Il existe une autre fonctionnalité stacktrace offerte par Throwable family - la possibilité de manipuler les informations de trace de pile.

Comportement Standard:

package test.stack.trace;

public class SomeClass {

    public void methodA() {
        methodB();
    }

    public void methodB() {
        methodC();
    }

    public void methodC() {
        throw new RuntimeException();
    }

    public static void main(String[] args) {
        new SomeClass().methodA();
    }
}

Trace de pile:

Exception in thread "main" java.lang.RuntimeException
    at test.stack.trace.SomeClass.methodC(SomeClass.java:18)
    at test.stack.trace.SomeClass.methodB(SomeClass.java:13)
    at test.stack.trace.SomeClass.methodA(SomeClass.java:9)
    at test.stack.trace.SomeClass.main(SomeClass.java:27)

Trace de pile manipulée:

package test.stack.trace;

public class SomeClass {

    ...

    public void methodC() {
        RuntimeException e = new RuntimeException();
        e.setStackTrace(new StackTraceElement[]{
                new StackTraceElement("OtherClass", "methodX", "String.java", 99),
                new StackTraceElement("OtherClass", "methodY", "String.java", 55)
        });
        throw e;
    }

    public static void main(String[] args) {
        new SomeClass().methodA();
    }
}

Trace de pile:

Exception in thread "main" java.lang.RuntimeException
    at OtherClass.methodX(String.java:99)
    at OtherClass.methodY(String.java:55)

Pour comprendre le nom: Une trace de pile est une liste d'exceptions( ou vous pouvez dire une liste de "Cause by"), 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 la première dans la dernière sortie (FILO), l'exception la plus profonde s'est produite au tout début, puis une chaîne d'exception a été générée une série de conséquences, l'exception de surface était la dernière s'est produite dans le temps, mais nous le voyons dans la première place.

Clé 1:Une chose délicate et importante ici doit être comprise est : la cause la plus profonde peut ne pas être la "cause première", car si vous écrivez un "mauvais code", cela peut provoquer une exception sous laquelle est plus profonde que sa couche. Par exemple, une mauvaise requête sql peut entraîner la réinitialisation de la connexion SQLServerException dans le bottem au lieu de l'erreur syndax, qui peut se trouver juste au milieu de la pile.

-> Localisez la cause racine au milieu est votre emploi.

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 se produisait à la première place pour ce bloc. Par exemple,

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)

Livre.java:16 a été appelé par Auther.java:25 qui a été appelé par Bootstrap.java: 14, Livre.java:16 était la cause première. Ici, attachez un diagramme triant la pile de traces dans l'ordre chronologique.

Juste pour ajouter aux autres exemples, il y a des classes internes(imbriquées) qui apparaissent avec le signe $. Par exemple:

public class Test {

    private static void privateMethod() {
        throw new RuntimeException();
    }

    public static void main(String[] args) throws Exception {
        Runnable runnable = new Runnable() {
            @Override public void run() {
                privateMethod();
            }
        };
        runnable.run();
    }
}

Entraînera cette trace de pile:

Exception in thread "main" java.lang.RuntimeException
        at Test.privateMethod(Test.java:4)
        at Test.access$000(Test.java:1)
        at Test$1.run(Test.java:10)
        at Test.main(Test.java:13)

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 que vous souhaitez tracer la cause de l'exception, un bon point de départ pour la comprendre est d'utiliser la Java Stack Trace Consoledans Eclipse. Si vous utilisez un autreE, 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.

Puis dans le Java perspective, cliquez sur le Console onglet (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 dans votre le 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 effectué sera le top de la pile, qui est la ligne supérieure (à 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 de si vous voulez examiner. Téléchargez les jars source, dans votre projet, ouvrez le dossier Referenced Libraries pour trouver votre jar pour votre module open-source (celui avec les fichiers de classe) puis faites un clic droit, sélectionnez Properties et attachez le jar source.