peinture étrange dans la fenêtre

Question

nous observons le comportement de la peinture étrange quand une exception non interceptée dans un écouteur swing comme ceci:

mytable.getSelectionModel().addListSelectionListener(
     new ListSelectionListener() { 
      @Override 
      public void valueChanged(ListSelectionEvent e) { 
       ... no try catch and npe exception happens 
      } 
     }); 

est-ce parce que nous jeter swing et interrompre la peinture/mises à jour normale? Dans la fenêtre qui lance, nous commençons à voir des boutons dans des endroits étranges, des barres de défilement apparaissent plusieurs fois. Si oui, que faire? essayer/attraper sur chaque auditeur de swing?

Answer 1

La raison de la peinture étrange est en effet l'exception lancée par l'auditeur. La solution consiste à éviter les exceptions chez les auditeurs. Cependant, l'intégration de chaque code d'écoute dans un bloc try/catch n'est pas la solution. La solution consiste à éviter les bogues et à les corriger lorsqu'ils apparaissent. La peinture étrange, avec la trace de pile de l'exception, est ce qui vous permet de détecter quand vous avez un bug dans votre code d'écoute. Une exception NullPointerException ne devrait jamais arriver. Si cela arrive, vous avez un bug. Attraper l'exception et l'avaler ne fera qu'aggraver le bug, car il ne sera pas détecté et provoquera, par exemple, l'affichage de fausses informations à l'utilisateur, ce qui pourrait provoquer une action désastreuse basée sur cette mauvaise information.

Answer 2

Par défaut, Swing ne gère pas particulièrement bien les exceptions inattendues. Comme vous l'avez deviné, Swing ne récupère pas clairement dans votre situation particulière. Étant donné que des bogues se produisent, je préfère fournir un gestionnaire d'exceptions qui affiche une boîte de dialogue pour l'utilisateur. Cette boîte de dialogue aurait idéalement un bouton "Signaler un bug" qui permettra à l'utilisateur de vous renvoyer la trace de la pile par courrier électronique afin que vous puissiez résoudre le problème. La boîte de dialogue devrait également permettre à l'utilisateur d'ignorer le problème et de continuer. Lorsque la boîte de dialogue est fermée, vous devriez juste retourner normalement ce qui devrait laisser la file d'attente des événements AWT inchangée.

Ce type de boîte de dialogue est utile non seulement pour vos utilisateurs mais aussi pour tous ceux qui travaillent sur le code. Les développeurs se heurteront à des plantages plus fréquemment que les utilisateurs, et il est très utile d'avoir une boîte de dialogue où le développeur peut choisir d'enquêter sur le crash ou de simplement l'ignorer.

Voir ce fil connexe qui décrit comment mettre en place un gestionnaire d'exception:

How can I catch AWT thread exceptions in Java?