Pourquoi mon NullPointerException ne pas être pris dans mon bloc catch?

Question

J'ai un fil dans lequel je prends toutes les erreurs dans un grand, qui englobe tout bloc catch. Je le fais pour que je puisse signaler toute erreur, et non uniquement attendus, dans ma demande. Mon Runnable ressemble à ceci:

public final void run()
{
    try
    {
        System.out.println("Do things"); /* [1] */

        doUnsafeThings();
    }
    catch (Throwable t)
    {
        System.out.println("Catch"); /* [2] */

        recover();
    }
    finally
    {
        System.out.println("Finally"); /* [3] */
    }
}

Je me attends à la NPE d'être pris par le bloc catch Throwable. Au lieu de cela, la sortie à [2] n'est pas imprimé, ni est [3]. La sortie à [1] est imprimé.

Ce que je ne la console, est la suivante:

Uncaught exception java/lang/NullPointerException.

Que diable se passe ici?

Pour les dossiers judiciaires, j'utilise J2ME, et cela est en cours d'exécution dans l'émulateur v2.5.2 de WTK Sun.

Je suis tenté de le mettre vers le bas pour la mise en œuvre JVM dodginess mais je ne peux pas aider le sentiment que je manque juste quelque chose.

Afin de clarifier pour éviter tout doute (Comme l'exemple de code est évidemment modifié de mon code de production)

• Il n'y a rien en dehors du try / catch / finally dans la méthode d'exécution.
• Il y a un System.out.println au début de chacun de ces blocs -. Ce qui suit ne devrait pas importer ces déclarations console

Answer 1

La réponse se trouve que je suis un idiot. Je vous expliquer ce qui se passait mal, mais nous allons simplement l'appeler « l'un de ces insectes ».

J'avais oublié un instant que le fil qui a couru le runnable était une classe de fil personnalisé (Pour contourner quelques bugs Nokia). Il a appelé à plusieurs reprises run() entre les appels à une méthode canWait().

La méthode canWait était responsable de l'échec, et l'exécution n'a pas été un échec du tout. Pour couronner le tout, je console aveuglement et complètement, mais mal cité par hasard la séquence des événements dans ma question.

Answer 2

On dirait que vous aurez besoin d'essais et d'erreurs. Puis-je suggérer:

try {
    doEvilStuff();
} catch (NullPointerException ex) { 
    System.out.println("NPE encountered in body"); 
} catch (Throwable ex) {
    System.out.println("Regular Throwable: " + ex.getMessage());
} finally {
    etc...
}

En ayant une prise explicite pour NullPointerException, il devrait devenir évident si l'exception est à l'intérieur du bloc d'essai ou un bloc catch / finally.

Answer 3

D'accord, c'est une conjecture sauvage ... mais il expliquerait les choses.

Il est évident que votre code est pas en fait qui - donc je suppose que vos prises (ou enfin) le bloc est soit en train de faire quelque chose avant qu'il ne se connecte quoi que ce soit, ou il utilise un enregistreur différent du bloc try. De toute façon, je soupçonne que ce soit la prise ou le bloc finally est de lancer l'exception.

Je ne pense pas que vous avez une trace de la pile ...

EDIT: D'accord, si c'est juste System.out.println, est-il quelque chose dans l'argument qui pourrait explosera Par exemple:

catch (Throwable t) {
    // Will go bang if t.getCause() returns null
    System.out.println(t.getCause().getMessage());
}

Si c'est juste System.out.println("Constant") simple, il est très étrange.

Savez-vous (par exemple des lignes de journaux dans le bloc try) dans quelle mesure le bloc try est réellement obtenir?

Answer 4

Quand je regardais votre code, il semble que Recover () jette une exception, si les conseils donnés par Jon serait excellent à suivre.

Si vous nous avez donné une trace de la pile, vous pouvez obtenir une meilleure aide.

Lorsque je tente d'attraper des exceptions que je fais quelque chose comme ceci:

try {
  doSomethingBad();
} catch(Exception e) {
   try {
      LogException(...);
   } catch(Exception e) {}       
} finally {
}

Je n'aime pas des exceptions nid, mais je ne veux pas que mes lancers de bloc sur les exceptions.

Answer 5

Comme vous le mentionnez que vous utilisez un Runnable - ce que cela signifie par hasard que vous utilisez plusieurs threads ainsi? Si la méthode doUnsafeThings() génère en interne un thread différent à nouveau et qui produit l'exception, vous ne pouvez pas l'obtenir dans le fil de votre bloc catch est. Voir http: //java.sun .com / J2SE / 1.5.0 / docs / api / java / lang / Thread.UncaughtExceptionHandler.html

Answer 6

Il est généralement une mauvaise pratique pour attraper NullPointerException.

Les programmeurs attrapent généralement NullPointerException dans trois circonstances:

The program contains a null pointer dereference. Catching the resulting exception was easier than fixing the underlying problem.
The program explicitly throws a NullPointerException to signal an error condition.
The code is part of a test harness that supplies unexpected input to the classes under test. 

De ces trois circonstances, seul le dernier est acceptable. suivant ce lien:

Catch NullPointerException

Answer 7

Est-il possible que le fil est tué par un autre code? En général, un bloc finally est toujours exécutée à moins que le fil est anormalement mis fin, soit par System.exit () ou quelque chose de similaire.

Answer 8

• Êtes-vous sûr que vous êtes à la recherche au bon endroit dans le code? À savoir, est le doUnsafeThings () bloquer vous protectrice de la trace de la pile?

• Peut-être qu'il ya un problème avec votre méthode de construction, et vous déboguez une ancienne version du code?

Answer 9

il suffit d'ajouter une certaine exploitation forestière dans les doUnsafeThings (); pour voir si cette méthode est en train de faire ce que vous attendez (mettre un enfin par exemple attraper et essayer quelque chose log)