Discussion :

[Invité]

Bonjour,

Suite à un choix de conception mûrement réfléchi, j'ai décidé de ne laisser aucune exception dans mon code.

Je me demande comment faire pour intercepter une exception puis simplement lancer une erreur correspondante, en perdant le moins d'informations possible. Pour l'instant je n'utilise qu'une fonction levant une exception et voici comment je l'encapsule :

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
  void sleep(long milliseconds) {
    try {
      Thread.sleep(milliseconds);
    }
    catch (InterruptedException e) {
      throw new Error(e.getMessage());
    }
  }

D'après la documentation, il y a plein d'autres informations sur une exception "Throwable", notamment un "stack trace", une "cause", une courte description (toString). Je me demande si créer une classe d'erreur pour chaque exception ne sera pas un peu lourd (exemple InterruptedException -> InterruptedError). Quelqu'un à une idée ?

[adiGuba]

Salut,

Suite à un choix de conception mûrement réfléchi, j'ai décidé de ne laisser aucune exception dans mon code.

Le choix est peut-être un peu extrême. Certaines exceptions peuvent rentrer dans des cas "possibles" où un traitement reste valable

Je me demande comment faire pour intercepter une exception puis simplement lancer une erreur correspondante, en perdant le moins d'informations possible.

Il faut bien encapsuler, mais en lui passant carrément l'exception originale car dans ton exemple tu perds plein d'info dont le stacktrace !
De plus perso j'aurais tendance à préférer une RuntimeException qu'à une Error qui est généralement utilisé par la JVM.
Pour tout conserver il faut simplement passer l'exception source en "cause", par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
catch (InterruptedException e) {
      throw new RuntimeException(e);
}

Ici l'exception sera mis en cause de la RuntimeException, et tu conservera toutes les infos


Seul défaut : tu as un double-stacktrace, celui du RuntimeException suivi de celui de l'exception originale :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
Exception in thread "main" RuntimeException: java.io.IOException: BaDaBoum
	at ...
	at ...
	at ...
Caused by: java.io.IOException: BaDaBoum
	at ...
	at ...
	at ...
        ... 20 more

Le problème c'est que si le stacktrace est trop long il peut être tronqué à la fin, et que c'est donc celui de la source qui sera coupé...


Tu peux éviter cela en ignorant la génération du stacktrace de ton exception, par exemple en te créant ta propre exception de la sorte :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
public class UncheckedException extends RuntimeException {
 
        public UncheckedException(Throwable source) {
                super(source);
        }
 
        public Throwable fillInStackTrace() {
                // Cette méthode génère normalement le stacktrace
                // On ignore cette étape qui ne nous interresse pas
                // dans le cas précis
                return this;
        }
}

Désormais le stacktrace de ton exception sera vide, et on aura ainsi directement le stacktrace de l'exception source :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
Exception in thread "main" UncheckedException: java.io.IOException: BaDaBoum
Caused by: java.io.IOException: BaDaBoum
	at ...
	at ...
	at ...
	at ...
	at ...
	at ...

Je me demande si créer une classe d'erreur pour chaque exception ne sera pas un peu lourd (exemple InterruptedException -> InterruptedError). Quelqu'un à une idée ?

C'est clairement trop lourd !
Il est préférable d'utiliser une seule et unique exception "englobante".
Si tu veux récupérer l'exception source tu peux tout simplement utiliser getCause(), voir la remonter en rajoutant une méthode de la sorte dans la classe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
        public void reThrow() throws Throwable {
                throw getCause();
        }

Ainsi par la suite tu peux faire quelque chose comme cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
UncheckedException e = ...
try {
    e.reThrow();
} catch (IOException e) {
    // c'est une IOException...
} catch (...)

Car dupliquer toutes les exceptions risque d'être très lourd et peu pratique pour un intérêt relativement faible...






Sinon, il existe carrément un moyen de remonter silencieusement n'importe quel exception tel quel, mais c'est un hack pas forcément très propre qui bidouille avec plusieurs éléments du langage, et qui est assez long à expliquer.
J'ai une ébauche de billet blog là dessus mais je ne sais pas quand j'aurais le temps de finir...


a++

[tchize_]

je rajouterais que l'exemple que tu as donné ext exactement un contre exemple de l'endroit ou il est judicieux de relancer une erreur. Une interruptedException, c'est juste un autre thread qui a demandé au tiens de se réveiller (via l'appel à interrupt()), c'est tout sauf un cas d'erreur et devrais donc etre traité correctement plutot que de renvoyer une error


Aussi pour le tronquage des stacktraces, il n'y a pas vraiment à s'inquiéter, la jvm ne fait que tronquer l'affichage en supprimant les parties commune du stacktrace entre la cause et l'exception/erreur finale, ca allège l'affichage

[Invité]

Quelle réactivité ! Merci beaucoup pour le tuyau !

Ta méthode est bien plus propre que ce que j'aurai pu espérer. Je vais faire une classe UncheckedException exactement comme la tienne, sauf que je vais remplacer la signature du constructeur par :

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

  public UncheckedException(Exception source) {

Car je ne transformerais jamais une Error en UncheckedException, donc pas besoin d'accepter n'importe quelle Throwable en paramètre. Il n'y a pas de problèmes à faire cela ?

En tout cas merci pour ta réponse de qualité, qui me permet de garder toutes les informations des exceptions (même le statut d'exception), sans avoir à les déclarer

@tchize_ : Effectivement, c'est pas très futé, mais pour l'instant je laisse ceci en erreur fatale afin de m'en appercevoir si elle arrive lors d'un de mes tests, afin de voir qu'est ce qui pourrait la déclencher. Comme j'utilise la fonction sleep pour séparer deux affichages graphiques, je pourrait me contenter, quand le programme sera fini, d'ignorer cette exception.

[adiGuba]

je rajouterais que l'exemple que tu as donné ext exactement un contre exemple de l'endroit ou il est judicieux de relancer une erreur. Une interruptedException, c'est juste un autre thread qui a demandé au tiens de se réveiller (via l'appel à interrupt()), c'est tout sauf un cas d'erreur et devrais donc etre traité correctement plutot que de renvoyer une error

Pas forcément... Une InterruptedException survient seulement lorsque le thread reçoit un "interrupt", et dans ce cas il est logique d'arrêter le thread. Donc remonter une exception n'est pas forcément une erreur, à moins que l'on ai mis en place un autre mécanisme pour arrêter le thread.

Car je ne transformerais jamais une Error en UncheckedException, donc pas besoin d'accepter n'importe quelle Throwable en paramètre. Il n'y a pas de problèmes à faire cela ?

Je n'y vois aucun problème...

a++