Chalut,
 
Il y a une question que je me pose depuis un moment et à laquelle je n'ai pas encore trouvé de "best practice", ça concerne la levée d'exception lors de la phase d'instanciation d'un singleton.
 
Dans mon exemple, je veux créer une classe AppProperties de type singleton qui permet de centraliser mes constantes (chargées depuis un fichier de properties). Pour lire la valeur des constantes, je fais:
 

 
Ma méthode statique getSingleton() me retourne mon instance de AppProperties en la créant si nécessaire en appelant le constructeur, lequel appel une méthode init(). Cette méthode lit depuis un fichier le paramétrage, je peux donc avoir des IOException qui sont levées.
 
Comment puis-je gérer la levée d'exception lors de l'exécution de la méthode init() ??? Je me vois mal propager l'exception au constructeur qui la relancerait, ça me semble un peu crade... D'un autre côté, je vois mal l'exception relancée par méthode statique getInstance()...
 
Comment gère-t-on ce genre de problème ??? Est-ce-que je m'y prends mal ??? Dois-je faire un System.exit(-1) en cas de levée d'exception ???

Tout d'abord, dans le principe, un constructeur peut tout à fait lever une exception, c'est tout sauf crade : comment sinon indiquer en "retour" du new que l'objet n'a pas pu être correctement construit ?
 
Maintenant, le problème, c'est que si tu as 50 singletons différents, les 50 sont peut-être susceptibles de lever une exception, et chacune est susceptible de bloquer le reste du programme. Cependant, n'oublie jamais que ton singleton n'est pas destiné à être toujours appelé depuis une application Java. Demain, tu l'inclueras peut-être à une applet ou une servlet. Il est largement préférable que seule la classe du main() se permette de faire des System.exit().
 
Ce que je peux te proposer, c'est de te définir une classe standard SingletonInitializationError, qui hériterait de Error, par exemple. Le constructeur pourrait alors lever une exception, que le getInstance() propagerait sous la forme d'une SingletonInitializationError jusqu'au niveau où ce type d'exception est traitable : le main() dans une application, le run() dans une applet, un thread ou une servlet.

 
OK, je trouvais ça crade car je n'avais jamais croisé ce cas de figure, ça me semblait bizzarre. A savoir...
 
[citation]
Maintenant, le problème, c'est que si tu as 50 singletons différents, les 50 sont peut-être susceptibles de lever une exception, et chacune est susceptible de bloquer le reste du programme. Cependant, n'oublie jamais que ton singleton n'est pas destiné à être toujours appelé depuis une application Java. Demain, tu l'inclueras peut-être à une applet ou une servlet. Il est largement préférable que seule la classe du main() se permette de faire des System.exit().[/citation]
 
Oui, en effet, je me disais bien que le System.exit() était à proscrire. Ton explication est très censée    
 
[citation]
Ce que je peux te proposer, c'est de te définir une classe standard SingletonInitializationError, qui hériterait de Error, par exemple. Le constructeur pourrait alors lever une exception, que le getInstance() propagerait sous la forme d'une SingletonInitializationError jusqu'au niveau où ce type d'exception est traitable : le main() dans une application, le run() dans une applet, un thread ou une servlet.
[/citation]
 
Je ne connaissais même pas l'existence de la classe Error! Je viens encore d'apprendre quelquechose.  
 
En tant cas, merci BifaceMcLeOD, tes réponses sont toujours très claires et précises  

Juste un détail, en java 1.4 je signale l'existance du package java.util.prefs et particulièrement la classe java.util.prefs.Preferences
 
http://java.sun.com/j2se/1.4.2/doc [...] mmary.html
 
c'est très pratique.

Je ne connaissais pas non plus. Malheureusement, mon JRE n'est qu'en v1.3.1
 
Ce sera utile sur d'autres projets

D'après le JDK, il y a 3 catégories d'exceptions :

• celles qui héritent de java.lang.Exception, qui indiquent des cas d'erreur qu'une application "raisonnable" peut vouloir traiter. Celles-là doivent être déclarées dans les clauses "throws".
• celles qui héritent de java.lang.RuntimeException, qui sont des cas d'erreur considérés comme normaux mais exceptionnels dans une exécution correcte. Celles-là n'ont pas besoin d'être déclarées dans les clauses "throws".
• celles qui héritent de java.lang.Error : celles-là indiquent des cas d'erreurs suffisamment graves (voire fatales) pour qu'une application "raisonnable" (dixit encore le JDK) ne les traite pas. Elles n'ont pas non plus besoin d'être déclarées dans les clauses "throws".

Ceci dit, ce n'est pas parce que le JDK conseille de ne pas traiter les erreurs qu'il ne faut pas le faire, au moins pour certaines. Ainsi, si tu écris un serveur en Java, ou même une application graphique un peu gourmande, il est recommandé de traiter les éventuelles java.lang.OutOfMemoryError. Normalement, ça ne devrait jamais arriver, mais si jamais ça arrive, il est de bon ton que le serveur ou l'application sache en survivre...

Si tu n'es pas en JDK 1.4, alors les exceptions ne sont pas chaînables. Dans ce cas, je te conseille de permettre de lier un SingletonInitializationError à une autre exception :

Ainsi cette sous-classe d'Error n'est plus qu'une encapsulation de l'exception réellement levée, ce qui permet d'uniformiser la récupération de l'exception sous-jacente tout en limitant clairement la portée de cette récupération.

 
Je connaissais les 2 premières mais par la 3ème catégorie... Ceci dit comment peux-tu traiter les OutOfMemoryError dans une application ? En appelant le garbage collector explicitement ?

Imagine que dans une application avec une interface graphique, l'utilisateur te demande d'ouvrir un fichier très très gros, et que son chargement -- et sa transformation en la représentation interne du programme -- déclenche une OutOfMemoryError. Il suffit alors d'interrompre le chargement en cours de route, et d'afficher une jolie boite de dialogue d'excuse à l'utilisateur.
Si, en écrivant le programme, tu as bien fait attention de ne pas garder de référence sur les objets chargés avant la fin du chargement (hors variables locales, bien sûr), l'interruption du chargement en cours de route libérera la mémoire prise par les objets temporaires presque immédiatement, sans même appeler explicitement le GC.
 
edit> Error hérite de Throwable et non d'Exception, c'est pour cela qu'elle est beaucoup moins connue. Et puis il faut quand même admettre que c'est plutôt rare de créer des sous-classes d'Error !  

pourquoi pas de RuntimeException plutot ??? ca me parait plus adapté ...

je connaissais pas non plus (j'ai pas encore nivestigué le 1.4   ).
Ca sauve ca en registry sous win ?

Je pense pas, plutôt dans le truc des applications de l'utilisateur.  
Sous OSX ça sauve au bon endroit en tout cas :

Chez Apple ils sont fans de ce format (et la classe concrête est bien une classe d'Apple).

Question de gravité d'erreur. Si l'on suit les définitions de 3 catégories d'exceptions, l'erreur d'initialisation d'un singleton ne relève pas des erreurs "normales" dans la vie d'un programme, donc serait plutôt une Error plutôt qu'une RuntimeException. Mais c'est une distinction assez subtile, je te l'accorde.

ouais je trouve aussi.
 
Pour moi Error c'est des erreurs "grave de chez grave" ... J'ai toujuors fait hérité mes exceptions d'initialisation de Runtime.
 
Un des raisons à ca c'est que si quelque part je catch Exception, je considère que je suis en droit de récupérer une erreur d'inititialisation non prévue ...

Là non, il peut continuer avec des paramètres pris ailleur.
Error c'est des trucs style : ÇaVaCouperChérieError ou tout au plus tu peux essayer de dire "ça va trancher chérie !" avant que tout parte en vrille. Alors qu'avec une PneuDeLaChaussureÉclatéException qui dérive de RuntimeException on peut continuer.

Oui sauf que comme je le disais plus haut, on peut très bien récupérer une OutOfMemoryError sans avoir aucune instabilité ensuite dans la JVM...
 
Par ailleurs, benou, ta supposition est fausse. De nombreux articles de gourous te confirmeront que catcher Exception ne suffit pas quand on veut écrire du logiciel robuste : il faut catcher Throwable.

Je pars du principe que c'est intéressant de catcher une exception que si on sait quoi en faire. Catcher Throwable à tout bout de champ c'est n'importe quoi ! Qu'est ce que tu peux faire d'une exception dont tu ne connais rien ?
 
Ca peux servir dans certains cas, mais c'est quand même plutot rare ...
Faire un catch Throwable pour récupérer un singleton contenant des propriétés ca me paraitrait plutot louche
 
Nan vraiment, je reste sur mon idée du InitException qui étend RuntimeException ...

+1 sur beenou, catcher n'importe quoi et continuer dans n'importe quel état et si possible en vrac c'est n'importe quoi et sûrement pas de la robustesse.

Pas n'importe où. Evidemment, n'importe où, c'est inepte et dangereux. Par contre, en fin de run() dans un thread ou une servlet (avec le try correspondant au tout début), ça ne l'est pas.
Libre au programmeur d'en faire ce qu'il veut après, de son exception, bien sûr (envoyer dans le log, afficher une jolie boite de dialogue "Unexpected exception" si on est dans une appli Swing, etc).