LMa solution de la honte, c'est d'utiliser des exceptions �tendant RuntimeException. Comme c'est indiqu� dans la javadoc, il s'agit d'unchecked exception, c'est-�-dire que lorsque tu �cris un bloc try ... catch, � moins de sp�cifier explicitement que tu souhaites catcher ta classe d'exception, celle-ci passe � travers le try ... catch. C'est une m�thode particuli�rement sale parce que hors de la class envoyant cette exception, *personne* ne sait que tu l'envoies. Il est donc tr�s facilement possible de casser le thread ex�cutant la m�thode par ce moyen : ta m�thode envoie une exception �tendant Runtime, personne ne la catche (parce que le d�veloppeur n'est pas le m�me, qu'il s'est content� - et c'est fort louable de sa part - de lire la javadoc de la m�thode) et l'exception remonte jusqu'� Thread.run qui meurt aussit�t. R�sultat ? un programme aux fraises. C'est donc une solution � �viter � tout prix.
ben non ! car cela est inclus dans une esp�ce de boite noire. je veux bien la solution qui te fais honte pour voir ...
A la place, je te propose plut�t l'utilisation d'un ExceptionHandler : dans une classe, tu utilises un singleton que tous tes listeners connaissent. Lorsqu'une exception survient, le listener l'inscrit dans ce ExceptionHandler que ton objet de base conna�t �galement. Et tout va bien !
--
Nicolas Delsaux
"On apprend plus d'un bon savant en fureur que de vingt t�cherons lucides et laborieux."
