redéfinition exception handler Swing

Salut à tous.

Comme vous le savez surement, quand vous définissez un évènement quelconque sur un composant Swing, et que le code de cet évènement lance une exception (non catchée forcément), il ne se passe pratiquement rien, si ce n'est que dans la console s'affiche le stacktrace de cette exception.

Je voudrais savoir si Swing permet de redéfinir ce comportement, l'intérêt serait de mettre en place un fonctionnement à base d'affichage de boites de dialogue signalant l'erreur en lieu et place de cet affichage dans la console (qui, admettons le, est fort peu utile vu que dans 90% des cas on affiche pas la console dans une applic swing).

Je précise que j'ignore totalement si cela est possible, c'est juste qu'il me semblerait fort logique que les concepteurs de Sun aient prévu cette possibilité.

Merci d'avance pour ceux qui me répondront.

en fait, si çà arrive dans la console, c'est parce que tu a laissé remonter l'exception vers le Thread AWT. Ca ne devrais pas arriver. Pourquoi AWT l'affiche dans la console? Tout simplement parce qu'il n'y a pas d'autre comportement logique pour gérer une exception remontée alors qu'elle devrais pas l'etre. La solution? Tout simplement, "gérer" tes exception dans les évènements, c'est là que çà doit être géré!

Moui, tu ne m'apprends rien là. Et pour ce qui est du "c'est le seul comportement logique" je ne suis pas d'accord. Sun a décidé de mettre en place ce fonctionnement parce qu'il le jugeait utile, mais là où ça me semblerait vraiment logique ç'aurait été de permettre une redéfinition de ce comportement.

PS: au cas où, aussi bien les JSPs que les actions Struts et JSF ont toujours permis le lancement de toutes les exceptions (y compris catchées), elles redirigent simplement vers une page qui peut être définie par le développeur. Comme quoi tu vois, ça n'a rien d'une idée farfelue, et ça permet d'éviter trois tonnes de code redondant qu'il est impossible de réutiliser (obligation de faire des try/catch partout partout).

Après avoir vu ce message: http://www.javalobby.org/java/forums/t19003.html il semblerait que ce soit possible avec un hack sur une JVM de Sun mais que rien ne soit prévu dans Swing/AWT en standard. C'est quand même pourris :D

Tu peux toujours réécrire le thread awt si çà te chante. Perso je trouve anormal de laisser remonter des exceptions que tu peux prévoir. Pour les webapp, le problème est que la console ne sert strictement dans ce cas. De plus, certaines exeptions n'arrivent pas vers la page, mais quand même vers la console. De plus, les try/catch, c'est pas approprié pour du jsp, alors que pour du code java ....

essayer de gerer les exceptions qui remontent de partout en restant cohérent, c'est pas top.

D'accord, tu as raison.
Un autre avis?

Salut,

Citation:

---

Envoyé par tchize_

essayer de gerer les exceptions qui remontent de partout en restant cohérent, c'est pas top.

---

Je pense (et j'espère) que l'objectif n'est pas de tenter de récupérer le programme, mais bel et bien d'avoir une meilleure visibilité sur les exceptions inattendus.

:arrow: Plutôt que de laisser le programme continuer sans info (en général les appli graphique ne sont pas lié à une console), il est préférable d'afficher une joli boite de dialogue contenant les informations sur le bug, et éventuellement quitter le programme...


C'est facilement réalisable avec Java 5 et les UncaughtExceptionHandler :

Code:

---

1 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

public class JOptionPaneExceptionHandler implements UncaughtExceptionHandler { @Override public void uncaughtException(Thread t, Throwable e) { // On récupère le StackTrace dans une String : StringWriter stackWriter = new StringWriter(); e.printStackTrace(new PrintWriter(stackWriter));   // On crée un JTextArea qui contient le stacktrace : JTextArea stackTrace = new JTextArea(stackWriter.toString()); stackTrace.setEditable(false); // Que l'on met dans un JScrollPane : JScrollPane scrollStackTrace = new JScrollPane(stackTrace); scrollStackTrace.setPreferredSize(new Dimension(400,200));   // On crée le contenu du JOptionPane (message + scrollpane) : Object[] message = new Object[] { "Une exception est survenue dans le thread '" + t.getName() + "' : ", "(le programme va être fermé)", " ", scrollStackTrace };   // Et on affiche le tout dans une boite de dialogue : JOptionPane.showOptionDialog(null, message, "Erreur d'exécution du programme...", 0, JOptionPane.ERROR_MESSAGE, null, new Object[] {"Quitter"}, null); // Puis on ferme le programme System.exit(1); } }

---

Qu'il suffit d'associer à tout les threads pour intercepter les exceptions non traité par n'importe quels threads (y compris l'EDT), simplement en utilisant la ligne suivante :

Code:

---

Thread.setDefaultUncaughtExceptionHandler(new JOptionPaneExceptionHandler());

---

Ou bien si on ne veut l'utiliser que pour l'EDT :

Code:

---

1 2 3 4 5 6

SwingUtilities.invokeAndWait(new Runnable() { @Override public void run() { Thread.currentThread().setUncaughtExceptionHandler(new JOptionPaneExceptionHandler()); } });

---

a++

je suis pas expert, mais autant que je sache, çà ne va pas traiter les exception qui on lieu dans la pile AWT, car elle seront traitées de manière générique par le Thread AWT. Ces handler, pour autant que je les connaissent, concernent les exception qui remontent au delà de run(). Alors, à moins qu'à chaque exception remontée par un AWT le thread AWT meurt pour etre recréé, je suis pas sur de l'efficacité.

Après un test rapide cela semble fonctionner :

Code:

---

1 2 3 4 5 6 7 8

Thread.setDefaultUncaughtExceptionHandler(new JOptionPaneExceptionHandler());   SwingUtilities.invokeLater(new Runnable() { @Override public void run() { throw new IllegalStateException("Boum!"); } });

---

Je suppose que l'EDT doit doit simplement traiter toutes les exceptions en les renvoyant vers l'exception handler s'il existe ;)

a++