Pourquoi mon NullPointerException ne pas être attrapé dans mon bloc catch?

J'ai un thread dans lequel j'attrape toutes les erreurs dans un grand, qui englobe tout le bloc catch. Je fais ce que je puisse signaler toute erreur, et pas seulement ceux attendus, dans mon application. Mon Exécutable 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] */
    }
}

J'attendrais la NPE d'être pris par le Throwable bloc catch. Au lieu de cela, la sortie de [2] n'est pas imprimé, et il n'est ni [3]. La sortie de [1] est imprimé.

Ce que je fais sur la console, est-ce:

Uncaught exception java/lang/NullPointerException.

Ce qui sur terre se passe ici?

Pour les dossiers de la cour, je suis en utilisant J2ME, et c'est en cours d'exécution dans le Soleil du WTK v2.5.2 émulateur.

Je suis tenté de le mettre vers le bas à la JVM de la mise en œuvre dodginess mais je peux pas m'empêcher de penser que je suis juste en manque de quelque chose.

À préciser, pour éviter tout doute (Puisque le code de l'exemple est évidemment modifié mon code de production)

  • Il n'y a rien en dehors de la try/catch/finally bloc dans la méthode run.
  • Il existe un Système..println au début de chacun de ces blocs - Ce qui suit ceux de la console états ne devrait pas d'importance.
Est la sortie de [1] sur l'écran?
Oui, [1] est affiché.
Oh, et puis-je avoir votre autographe, M. Skeet? 😛

OriginalL'auteur izb | 2009-04-22

  1. 6

    La réponse se trouve que je suis un idiot. Je voudrais expliquer ce qui s'est passé, mais appelons ça "l'un de ces bugs".

    J'avais momentanément oublié que le thread qui a couru le praticable était une coutume classe thread (Pour contourner certains Nokia bugs). Il a appelé run() à plusieurs reprises entre les appels à un canWait() méthode.

    La canWait méthode a été responsable de l'échec, et d'exécuter n'était pas la faute à tous. Pour couronner le tout, j'ai une console de cécité et complètement, mais accidentellement mal cité, la séquence des événements dans ma question.

    S'il vous plaît laissez-nous savoir 🙂
    Curieux veulent savoir. Nous avons tous fait boneheaded choses.
    J'avais momentanément oublié que le thread qui a couru le praticable était une coutume classe thread (Pour contourner certains Nokia bugs). Il a appelé à exécuter() à plusieurs reprises entre les appels à un " canWait()' méthode. Le canWait méthode a été responsable de l'échec, et d'exécuter n'était pas la faute à tous. Pour couronner le tout, j'ai une console de cécité et complètement, mais accidentellement mal cité, la séquence des événements dans ma question.
    +1 et mes remerciements pour la suite de la réponse!

    OriginalL'auteur izb

  2. 5

    Dirait que vous aurez besoin de quelques 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...
}

    Par la présence d'une explicite attraper une exception NullPointerException, il devrait devenir évident si l'exception est de l'intérieur du bloc try ou catch/finally bloc.

    OriginalL'auteur Mike

  3. 4

    Bon d'accord, c'est un sauvage deviner... mais il serait expliquer les choses.

    Évidemment, votre code n'est pas fait que je pense, c'est que vos prises (ou enfin) de bloc est soit de faire quelque chose avant qu'il enregistre rien, ou il utilise un enregistreur différent que le bloc try. De toute façon, je pense que le catch ou le bloc finally est en train de lancer une exception.

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

    EDIT: Bon, si c'est juste System.out.println, est-il quelque chose dans l'argument qui pourraient aller au-bang? Par exemple:

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

    Si c'est juste simple System.out.println("Constant") puis, c'est très bizarre.

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

    Pas de trace de pile, pas (ne Peuvent pas l'attraper). Et ma mise à jour ma question s'adresse désormais à certains de vos réponse. Il n'y a pas de journalisation impliqué.. juste du Système..println.

    OriginalL'auteur Jon Skeet

  4. 2

    Quand j'ai regardé ton code, il semble que récupérer() lance une exception, si l'avis donné par Jon serait excellent à suivre.

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

    Lorsque j'essaie d'intercepter des exceptions-je faire quelque chose comme ceci:

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

    Je n'aime pas le nid des exceptions, mais je n'aime pas mon bloc catch de lever des exceptions.

    OriginalL'auteur James Black

  5. 2

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

    OriginalL'auteur Daniel Schneller

  6. 1

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

    Programmeurs généralement attraper NullPointerException de moins de 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, seule la dernière est acceptable. en suivant ce lien:

    Catch NullPointerException

    OriginalL'auteur za_al

  7. 0

    Est-il possible que le fil est d'être tué par un autre code? En général, un bloc finally est toujours exécuté, à moins que le fil est arrêté anormalement, soit par le Système.exit() ou quelque chose de similaire.

    Malheureusement, ce n'est pas possible. Le système n'a pas de sortie, et le code est construit pour CLDC 1.0 (en fait un sous-ensemble de l'API Java), ce qui signifie qu'il n'y a aucun moyen de mettre fin à un fil. Il ne fait pas partie de l'API - threads seule porte de sortie lors de l'exécuter() ferme.
    Pouvez-vous vérifier que votre fil est en fait de quitter? Est-il possible que le fil est toujours en vie, mais bloqué en raison d'une exception, quelque part, et n'apparaît qu'à la mort de l'extérieur?

    OriginalL'auteur Mr. Shiny and New 安宇

  8. 0

    • Êtes-vous sûr que vous êtes à la recherche à la bonne place dans le code?
      I. e., est le doUnsafeThings() bloc vous protéger de la trace de la pile?

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

    OriginalL'auteur mfx

  9. 0

    juste ajouter un peu de journalisation dans le doUnsafeThings(); pour voir si cette méthode est de faire ce que vous attendez (e.g mettre un try catch finally et journal de quelque chose)

    OriginalL'auteur silmx