Je d=E9veloppe une application Swing sous Java 1.4.2 et je souhaite
traiter sp=E9cifiquement toutes les exceptions non intercept=E9es.
La classe ThreadGroup et sa m=E9thode uncaughtException(...) est l=E0
pour =E7a me direz vous !
Le probl=E8me c'est que les threads AWT cr=E9=E9s par la JVM sont
attach=E9s au groupe par d=E9faut 'main'. Et je ne peux pas modifier la
m=E9thode uncaughtException(...) de ce groupe.
En 5.0 on a la m=E9thode statique (et magique)
Thread.setDefaultUncaughtExceptionHandler(...) mais en 1.4.2 on fait
comment?
J'ai essay=E9 de cr=E9er une classe java.lang.ThreadGroup dans mon projet
et d'y copier-coller la source 1.4.2, dans l'id=E9e de modifier =E0 ma
sauce sa m=E9thode uncaughtException(...).
Mais la JVM continue =E0 utiliser la classe ThreadGroup du rt.jar pour
cr=E9er le groupe par d=E9faut (appel=E9 "main"). Un probl=E8me de
priorit=E9s de librairies? (je travaille sous NetBeans 5.0).
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
TestMan
bonjour à tous !
Je développe une application Swing sous Java 1.4.2 et je souhaite traiter spécifiquement toutes les exceptions non interceptées.
La classe ThreadGroup et sa méthode uncaughtException(...) est là pour ça me direz vous ! Le problème c'est que les threads AWT créés par la JVM sont attachés au groupe par défaut 'main'. Et je ne peux pas modifier la méthode uncaughtException(...) de ce groupe.
En 5.0 on a la méthode statique (et magique) Thread.setDefaultUncaughtExceptionHandler(...) mais en 1.4.2 on fait comment?
J'ai essayé de créer une classe java.lang.ThreadGroup dans mon projet et d'y copier-coller la source 1.4.2, dans l'idée de modifier à ma sauce sa méthode uncaughtException(...). Mais la JVM continue à utiliser la classe ThreadGroup du rt.jar pour créer le groupe par défaut (appelé "main"). Un problème de priorités de librairies? (je travaille sous NetBeans 5.0).
Des idées?
Merci d'avance.
-o
Bonjour,
Passer en 1.5.0 :o) ... ok elle était facile :P
Plus sérieusement, bricoler une classe ThreadGroup "maison" me semble pas trés évident sur du 1.4.2 par contre pourquoi ne pas passer par le JPDA ? A creuser ...
A+ TM
bonjour à tous !
Je développe une application Swing sous Java 1.4.2 et je souhaite
traiter spécifiquement toutes les exceptions non interceptées.
La classe ThreadGroup et sa méthode uncaughtException(...) est là
pour ça me direz vous !
Le problème c'est que les threads AWT créés par la JVM sont
attachés au groupe par défaut 'main'. Et je ne peux pas modifier la
méthode uncaughtException(...) de ce groupe.
En 5.0 on a la méthode statique (et magique)
Thread.setDefaultUncaughtExceptionHandler(...) mais en 1.4.2 on fait
comment?
J'ai essayé de créer une classe java.lang.ThreadGroup dans mon projet
et d'y copier-coller la source 1.4.2, dans l'idée de modifier à ma
sauce sa méthode uncaughtException(...).
Mais la JVM continue à utiliser la classe ThreadGroup du rt.jar pour
créer le groupe par défaut (appelé "main"). Un problème de
priorités de librairies? (je travaille sous NetBeans 5.0).
Des idées?
Merci d'avance.
-o
Bonjour,
Passer en 1.5.0 :o) ... ok elle était facile :P
Plus sérieusement, bricoler une classe ThreadGroup "maison" me semble
pas trés évident sur du 1.4.2 par contre pourquoi ne pas passer par le
JPDA ? A creuser ...
Je développe une application Swing sous Java 1.4.2 et je souhaite traiter spécifiquement toutes les exceptions non interceptées.
La classe ThreadGroup et sa méthode uncaughtException(...) est là pour ça me direz vous ! Le problème c'est que les threads AWT créés par la JVM sont attachés au groupe par défaut 'main'. Et je ne peux pas modifier la méthode uncaughtException(...) de ce groupe.
En 5.0 on a la méthode statique (et magique) Thread.setDefaultUncaughtExceptionHandler(...) mais en 1.4.2 on fait comment?
J'ai essayé de créer une classe java.lang.ThreadGroup dans mon projet et d'y copier-coller la source 1.4.2, dans l'idée de modifier à ma sauce sa méthode uncaughtException(...). Mais la JVM continue à utiliser la classe ThreadGroup du rt.jar pour créer le groupe par défaut (appelé "main"). Un problème de priorités de librairies? (je travaille sous NetBeans 5.0).
Des idées?
Merci d'avance.
-o
Bonjour,
Passer en 1.5.0 :o) ... ok elle était facile :P
Plus sérieusement, bricoler une classe ThreadGroup "maison" me semble pas trés évident sur du 1.4.2 par contre pourquoi ne pas passer par le JPDA ? A creuser ...
A+ TM
Insitu
TestMan writes:
Mais la JVM continue à utiliser la classe ThreadGroup du rt.jar pour créer le groupe par défaut (appelé "main"). Un problème de priorités de librairies? (je travaille sous NetBeans 5.0). Des idées?
Bonjour, Il me semble que pour surcharger les classes de base de java (ie. rt.jar), il est nécessaire de modifier le bootclasspath. Ce qui oblige à reconstruire un rt.jar avec les classes modifiées et les autres telles quelle.
Un peu hard qd même... Il y a certainement une solution plus simple et moins bas niveau en refactorant le code.
insitu.
TestMan <none@example.com> writes:
Mais la JVM continue à utiliser la classe ThreadGroup du rt.jar pour
créer le groupe par défaut (appelé "main"). Un problème de
priorités de librairies? (je travaille sous NetBeans 5.0).
Des idées?
Bonjour,
Il me semble que pour surcharger les classes de base de java
(ie. rt.jar), il est nécessaire de modifier le bootclasspath. Ce qui
oblige à reconstruire un rt.jar avec les classes modifiées et les
autres telles quelle.
Un peu hard qd même... Il y a certainement une solution plus simple et
moins bas niveau en refactorant le code.
Mais la JVM continue à utiliser la classe ThreadGroup du rt.jar pour créer le groupe par défaut (appelé "main"). Un problème de priorités de librairies? (je travaille sous NetBeans 5.0). Des idées?
Bonjour, Il me semble que pour surcharger les classes de base de java (ie. rt.jar), il est nécessaire de modifier le bootclasspath. Ce qui oblige à reconstruire un rt.jar avec les classes modifiées et les autres telles quelle.
Un peu hard qd même... Il y a certainement une solution plus simple et moins bas niveau en refactorant le code.
