Version imprimable
Bonjour, j'aimerais savoir pourquoi dans le code ci-dessous l'erreur n'est pas attrapée :question:
"fin try" est également affiché, comme si l'erreur arrivait à retardement... :weird:Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Salut,
On peut avoir le vrai code complet, parce qu'en l'état, ce code ne compile pas puisqu'il n'y a aucune méthode dans aucune classe, et qu'on ne sait pas ce qu'est exactement Stage (javafx.stage.Stage ?).
Si c'est un javafx.stage.Stage, et qu'on met ce code dans une méthode main(), une exception est soulevée lors de l'exécution de new Stage() avant l'exécution de w.getIcons().add(null);, donc l'hypothétique NullPointerException ne sera jamais soulevée, donc encore moins attrapée. Mais "fin try" n'est pas affiché.
Sinon, dans le cas général, si "fin try" s'affiche, et qu'une stack d'exception s'affiche (sans le "erreurattrapée"), y compris pour une NullPointerException, c'est parce que l'exception est produite dans un thread lancé dans l'initialisation de Stage.
Il suffit de placer ce code dans la méthode start() d'une sous-classe de Application, donc il s'exécute bien sur le thread JavaFX, et en commentant la ligne w.getIcons().add(null) l'erreur n'apparaît pas donc le problème provient bien de celle-ci.
nb:Il s'agit bien de la classe javafx.stage.Stage
Il ne suffit de rien du tout. Si tu veux qu'on réponde à ta question, tu fournis de quoi la reproduire ce qu'on ait besoin de faire des suppositions et surtout d'avoir à créer un snippet pour la réproduire. La stacktrace de l'exception serait utile aussi.
Dans ton cas, l'exception ne remonte pas à ton code, parce qu'elle est attrapée et affichée avant, ici :
com.sun.javafx.collections.ListListenerHelper$SingleChange.fireValueChangedEvent(ListListenerHelper.java:164)
Donc ton appel ne soulève pas la NullPointerException qui est affichée.
Je n'ai même pas pensé à regarder dans la pile tellement ça me semblait bizarre, cette méthode appelle le handler des erreurs non attrapées du fil en cours, ce qui est plutôt étonnant comme implémentation je trouve. On fait une opération à un endroit et au lieu que l'exception soit levée localement pour qu'on puisse faire le lien avec ce qu'on est en train de faire elle est bazardée dans un autre morceau de code qui forcément gérera l'exception de manière plus générale, c'est le genre d'erreur compliquée à déterrer. :aie:
Bref je vais devoir revoir mon code de gestion des exceptions.
Merci pour ton aide.
C'est pour éviter que le thread de JavaFx s'arrête. Les exceptions, c'est pour gérer ce qu'on ne maîtrise pas, ce qu'on ne peut prévoir. En théorie, comme tu sais que ça provoque une exception, tu ne devrais pas passer null en paramètre.
Pour ce que j'en pense c'est que tu modifies une liste observable -> donc quelques part le gestionnaire du Stage observe cette liste -> Donc il reagit a ton ajout -> c'est lui qui catch et affiche l'erreur -> donc elle ne remonte jamais dans ton code.
C'est ce qu'indique la 1ere trace visible:
En fait l'erreur est catchee au moment de la propagation a la ligne 164 de com.sun.javafx.collections.ListListenerHelper<E> :Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Apres une seconde erreur est levee si on essaie de rendre la fenetre visible.Code:
2
3
4
5
6
7
8
Il pourrait etre interressant de reporter le bug sur http://bugs.java.com/ en suggerant que les elements passes dans la liste ne doivent pas etre null (mais ca demanderait de surcharger toutes les methodes add(), addAll(), pour faire les verifs appropriees), ce qui n'est pas infaisable car dans le code de Stage on trouve :Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
Mais bon du coup ca casserait le contrat de l'interface List qui n'interdit pas du tout les valeurs null et donc pour le coup ils ne changeront sans doute rien. A noter cependant que Parent.getChildren().add() lance bien une exception lorsqu'on essaie d'inserter un noeud enfant null donc la solution n'est pas si exotique que cela.Code:
2
3
4
5
6
7
8
9
10
11
D'un autre cote une suggestion de verifier que la valeur de la liste n'est pas null aux lignes 696 et 1189 de Stage et de ne rien faire (c-a-d ne pas tenter d'acceder au peer natif) quand c'est le cas serait sans doute plus la bienvenue. Et, dans les deux blocs, remplacer :
Par :Code:
2
3
4
5
Ou :Code:
2
3
4
5
6
7
8
Code:
2
3
4
Bon ben j'ai soumis un rapport de bug qui suggere les deux solutions
Et voila :
Oracle : JDK-8181930 : Adding a null icon to a Stage prevents application startup
Open JDK : [JDK-8181930] Adding a null icon to a Stage prevents application startup
Pour une fois le transfert vers l'OpenJDK a ete rapide. Par contre pour la resolution.... faudra sans doute voir pour une maj post-JDK 9.
Merci pour les pavés. ^^
Une maj sur le problème des icônes nulle : [JDK-8181930] Adding a null icon to a Stage prevents application startup
Un fix sera intégré au JDK10 et peut-être backporté sur le JDK9. Il sont partis sur la solution d'interdire l'insertion d'une icône null dans la liste des icônes du Stage, un peu comme quand on fait parent.getChildren().add(null)