Envoyé par
thelvin
D'accord, j'ai pas mal exagéré la réalité, mais enfin, le principe est là : s'il y a exception à l'initialisation d'une classe, c'est pas un simple try catch qui va gérer et c'est pas souple du tout.
Ben justement... Cela ne sert à rien de déporter les try/catch. Qu'il soit à l'initialisation ou ailleurs le problème est le même. Que va-t-on faire lors du prochain try/catch ???
Surtout que cela risque de multiplier les try/catch à chaque fois que tu accèdera à l'enum , et que cela multiplie donc le risque de mauvais traitement des exceptions.
En clair au lieu d'avoir un FileNotFound au plus tôt, on se retrouve avec un NullPointerException à l'autre bout du code 
Envoyé par
thelvin
Bon courage pour se rendre compte que c'est parce qu'il n'a pas trouvé les images. Du coup, la différence entre ça et pas de contrôle du tout, elle est pas toujours évidente.
Ben justement : en remontant l’exception immédiatement, tu obtiens l'erreur immédiatement 
Le fait de remonter une "unchecked-exception" n'est pas sale ni moins bien. Au contraire même !!!
Si on peut gérer une alternative c'est bien de le faire. Par exemple dans le cas où le fichier d'image provient de l'utilisateur, on peut lui indiquer que le fichier n'existe pas et l'inviter à ressaisir le chemin... Mais si on n'a aucune alternative, autant laisser remonter l'erreur au plus tôt !
Si on est en mode console c'est "parfait" puisqu'on a notre erreur immédiatement (et pas trois heure après quand on a le malheur de faire le getImage()).
Le seul soucis c'est en mode graphique et/ou multithread, où on n'a pas forcément de vue sur la console.
Les unchekced-exceptions pouvant tuer un thread tout en laissant le programme continuer.
On peut pallier à cela via l'UncaughtExceptionHandler. Par exemple rien qu'avec ce petit bout de code, on a déjà quelque chose d'acceptable :
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
| class ErrorHandler implements Thread.UncaughtExceptionHandler {
public void uncaughtException(Thread t, Throwable e) {
// On transforme le stacktrace en "String" :
StringWriter writer = new StringWriter();
e.printStackTrace(new PrintWriter(writer));
String text = writer.getBuffer().toString();
// On crée une zone de texte pour afficher le stacktrace :
JTextArea textArea = new JTextArea(text);
JScrollPane scroll = new JScrollPane(textArea);
scroll.setPreferredSize(new Dimension(400, 200));
// On affiche une boite de dialogue avec toutes les informations :
Object[] message = {
"Le programme va s'arrêter car une erreur inattendue est survenue.",
"Merci de contacter le support technique.",
" ",
"Thread : " + t.getName(),
" ",
"Détail : ",
scroll
};
JOptionPane.showMessageDialog(null, message,
"Erreur d'application", JOptionPane.ERROR_MESSAGE);
// On quitte :
System.exit(0);
}
} |
Avec cette simple instruction en début de programme, on gère alors les unchecked-exceptions en affichant un message avant de quitter :
Thread.setDefaultUncaughtExceptionHandler(new ErrorHandler());
On peut même y greffer une remonté d'info automatique par email ou autre
a++
Problème Unhandled exception dans un enum
Répondre avec citation
)
Partager