JDK 7: Proposition 8 : rethrow exceptions

Aujourd'hui :

Code:

---

1 2 3 4 5 6 7

try { doable.doit(); // Throws several types } catch (Throwable ex) { logger.log(ex); throw ex; // Error: Throwable not declared }

---

Demain :

Code:

---

1 2 3 4 5 6 7

try { doable.doit(); // Throws several types } catch (final Throwable ex) { logger.log(ex); throw ex; // OK: Throws the same several types }

---

Non, je n'aime pas le principe... je préfère devoir ajouter un throws Exception à ma méthode pour être certain que celui qui l'appel est conscient du problème...

Là, je suis un peu perplexe. Car il faut prendre en compte la prop 7. Si on peut catcher plusieurs types d'exception, on peut alors écrire :

Code:

---

1 2 3 4 5 6

try { doable.doit(); // Throws ExceptionType1 or ExceptionType2 } catch (ExceptionType1, ExceptionType2 : ex) { logger.log(ex); throw ex; // OK, because ExceptionType1 and ExceptionType2 are already declared }

---

Vous me suivez ?
Qu'en pensez-vous ?

Contre,

je vois pas bien l'intérêt ni l'application ..

Cela veut-il dire que des exceptions non Runtime pourraient être "throwée" (dieu du français pardonnez moi :aie:) sans déclaration préalable dans la signature de la méthode ?

Je veux bien que le compilo ajoute le throws a la signature automatiquement mais jusqu'a nouvel ordre je ne suis pas un compilo, je le vois comment moi ce truc ? En parcourant tout le code de chaque méthode a chaque fois ? Et la javadoc dans tout ça ?

Bulbo ;)

Contre, idem que bulbo.

Citation:

---

Envoyé par bulbo

Cela veut-il dire que des exceptions non Runtime pourraient être "throwée" (dieu du français pardonnez moi :aie:) sans déclaration préalable dans la signature de la méthode ?

---

Pas du tout !

Je pense que vous n'avez pas bien compris, ou alors c'est moi :mrgreen:

Je reformule l'exemple avec plus de détail.

Avant :

Code:

---

1 2 3 4 5 6 7 8 9 10

public void myMethod(String prefix, String suffix) throws Throwable { try { File.createTempFile(prefix, suffix); // Could throw IllegalArgumentException, IOException or SecurityException } catch (Throwable ex) { logger.log(ex); throw ex; // myMethod could throw a Throwable } }

---

Après :

Code:

---

1 2 3 4 5 6 7 8 9 10

public void myMethod(String prefix, String suffix) throws IOException { try { File.createTempFile(prefix, suffix); // Could throw IllegalArgumentException, IOException or SecurityException } catch (Throwable ex) { logger.log(ex); throw ex; } }

---

Sachant que dans mon exemple, IllegalArgumentException et SecurityException n'ont pas besoin d'être déclarée en throws car elles sont des RuntimeException. Mais elles seront cependant interceptées dans le catch.

Est-ce que mon exemple convient ?

Citation:

---

Envoyé par bobuse

Je pense que vous n'avez pas bien compris, ou alors c'est moi :mrgreen:

Je reformule l'exemple avec plus de détail.

Avant :

Code:

---

1 2 3 4 5 6 7 8 9 10

public void myMethod(String prefix, String suffix) throws Throwable { try { File.createTempFile(prefix, suffix); // Could throw IllegalArgumentException, IOException or SecurityException } catch (Throwable ex) { logger.log(ex); throw ex; // myMethod could throw a Throwable } }

---

Après :

Code:

---

1 2 3 4 5 6 7 8 9 10

public void myMethod(String prefix, String suffix) throws IOException { try { File.createTempFile(prefix, suffix); // Could throw IllegalArgumentException, IOException or SecurityException } catch (Throwable ex) { logger.log(ex); throw ex; } }

---

Sachant que dans mon exemple, IllegalArgumentException et SecurityException n'ont pas besoin d'être déclarée en throws car elles sont des RuntimeException. Mais elles seront cependant interceptées dans le catch.

Est-ce que mon exemple convient ?

---

Ton exemple est construit pour marcher alors forcément il te convient :mrgreen:

Bon du coup j'ai relu l'exemple, et un exemple que je dois relire 3 fois pour en comprendre le fonctionnement me laisse a penser que la maintenance de ce genre de trucs risque d'être piégeuse..

Je pense que la methode englobante (et que l'on ne voit pas dans l'exemple, pourtant ça aurait aidé) déclare les throws des "several type" mais pas de Throwable, ce qui explique qu'aujourd'hui on soit obligé d'écrire un catch pour chaque type d'exception pour faire la même chose.

Maintenant que va-t'il se passer si une exception non déclarée dans le throws arrive ? Le compilo saura que ce n'est pas bon et pourra indiquer que telle exception doit être catchée ? Ou bien l'exception sera rethrowée (:aie:) et on aura un crash au runtime ?

Ca manque de précision; dans le cas ou le compilo retrouve ses petits c'est bon pour moi sinon a proscrire absolument.

Bulbo ;)

Citation:

---

Envoyé par bulbo

Je pense que la methode englobante (et que l'on ne voit pas dans l'exemple, pourtant ça aurait aidé) déclare les throws des "several type" mais pas de Throwable, ce qui explique qu'aujourd'hui on soit obligé d'écrire un catch pour chaque type d'exception pour faire la même chose.

Maintenant que va-t'il se passer si une exception non déclarée dans le throws arrive ? Le compilo saura que ce n'est pas bon et pourra indiquer que telle exception doit être catchée ? Ou bien l'exception sera rethrowée (:aie:) et on aura un crash au runtime ?

---

Je ne suis toujours pas sûr qu'on parle de la même chose.

Ici, il n'est pas question de permettre de jeter des exceptions qui ne sont pas déclarées dans le throws.
Il est bien question de permettre de déclarer dans le throws uniquement les exceptions pouvant être lancées par un throw, sachant que dans les types d'exceptions pris en compte sont bien ceux des méthodes englobées par le try et nom le type du catch.

Mais c'est vrai que l'exemple n'est pas très clair.
vbrabant, si tu pouvais nous éclairer un peu plus :)

On parle de la même chose rassure toi.

Mais si tu regardes l'exemple, il y a un catch Throwable, qui, par définition catch tout.
Imaginons que dans un premier temps tu ai déclaré dans ton throws toutes les exceptions que tu sais possible et que plus tard tu rajoutes un appel qui lance une nouvelle exception et que tu l'oublie celle la..

Que va faire le catch ? Catcher tout comme l'utilisation de Throwable laisse a penser ou ne va-t'il catcher que les exceptions déclarées dans le throws ?

En fait je vois mal comment il pourrait savoir quoi catcher et il catchera tout (cas de try imbriqués: qui catch quoi ?) et donc rethrow de tout 8O

Comment ne plus avoir de problème de compil dans ce cas, il y aura de toute façon problème, ou ira la nouvelle exception ? Qui la catchera ? Ou aura-t'on droit a une Runtime ?

Bref je ne veux pas de ce système, pourquoi ne pas faire des exceptions qu'on ne catch jamais et qui ne plante rien a la C++ tant qu'on y est ..

Bulbo ;)

Citation:

---

Envoyé par bulbo

Mais si tu regardes l'exemple, il y a un catch Throwable, qui, par définition catch tout.
Imaginons que dans un premier temps tu ai déclaré dans ton throws toutes les exceptions que tu sais possible et que plus tard tu rajoutes un appel qui lance une nouvelle exception et que tu l'oublie celle la..

Que va faire le catch ? Catcher tout comme l'utilisation de Throwable laisse a penser ou ne va-t'il catcher que les exceptions déclarées dans le throws ?

---

Le catch fera comme avant, il catchera tout ce qui hérite du type utilisé (ici Throwable, mais ça peut être autre chose). Par contre, le throws de la signature devra être modifiée pour ajouter ta nouvelle exception.

Citation:

---

Envoyé par bobuse

Le catch fera comme avant, il catchera tout ce qui hérite du type utilisé (ici Throwable, mais ça peut être autre chose). Par contre, le throws de la signature devra être modifiée pour ajouter ta nouvelle exception.

---

Je ne vois pas très bien comment le compilo pourrait bien se débrouiller avec ça.. surtout en cas de try catch imbriqué qui lance quoi, qui doit déclarer quoi ..

Bref pas convaincu du tout par ce truc..

Bulbo ;)

Pour cette évolution, même si il faut bien faire attention au mot clé final, peut être ambigu dans la lecture

Pour, j'ai ai marre d'initialiser de nouvelles exceptions et de les chainer a la precedente avec initCause() a chaque fois.

J'ai voté contre car je pense que ça permettrais une gestion plus laxiste des exception et que c'est mauvais.

Par contre, en lisant les différents messages je me pose des question quand à la compréhension, donc si l'auteur original, vbrabant, pouvait un peu plus expliquer ce serait sympa.

Effectivement, la proposition peut être mal comprise, et laisser à penser à du laxisme.
Je pense que c'est la notation qui n'est pas très explicite. Qu'est-ce qu'on pourrait trouver de mieux ?

Code:

---

catch (? extends Throwable ex)

---

Bof :aie:

Encore une fois, le problème ne se poserait pas avec la proposition 7, et ce serait beaucoup moins ambigü !! :roll:

Un petit contre, non pas contre la proposition mais contre la syntaxe qui est incompréhensible à mon avis...

D'ailleurs je pense que certain ne l'on pas bien compris...



En fait il ne s'agit pas réellement d'un vrai catch puisqu'on laisse remonter les exception à chaque fois. Il s'agit plus d'un "filtre" qui permettrait de voir passer les exceptions juste avant de les remonter, par exemple pour les logger.


Imaginer une méthode toute simple qui pourrait remonter des IOException :

Code:

---

1 2 3 4

public void method() throws IOException { method1(); // throws IOException method2(); }

---

Comme toutes méthodes elle peut également remonter des RuntimeException (NullPointerException par exemple) ou des Error (OutOfMemory).



Maintenant si vous voulez rajouter un log au sein de cette méthode juste pour conserver une trace des problèmes rencontré tout en continuant à les remonter, il vous faut traiter chaque cas :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

public void method() throws IOException, SQLException { try { method1(); // throws IOException method2(); } catch (IOException e) { log("..."); throw e; } catch (RuntimeException e) { log("..."); throw e; } catch (Error e) { log("..."); throw e; } }

---

Cette proposition vise à permet cela plus simplement, en utilisant un catch unique :

Code:

---

1 2 3 4 5 6 7 8 9

public void method() throws IOException { try { method1(); // throws IOException method2(); } catch (final Throwable t) { log("..."); throw t; } }

---

:arrow: En fait ce catch là ne traite pas les exceptions et les laisse remonter, mais ce code ne marche pas car Throwable pourrait correspondre à n'importe quoi, or dans ce cas précis ce ne peut être qu'une IOException, une RuntimeException ou une Error ce qui est parfaitement compatible avec la déclaration de notre méthode...



Bref ce bloc catch ne correspond qu'à un simple passage pour l'exception qui sera quand même remonté... et du coup la syntaxe ne me plait pas.
J'opterais plutôt pour ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10

public void method() throws IOException, SQLException { try { method1(); // throws IOException method2(); } catch (Throwable t) { // Toutes les exceptions qui arrive ici seront // remonté après l'exécution de ce bloc : log("..."); } }

---

Ici le bloc throws() est exécuté lorsqu'un élément est remonté, mais cela ne traite pas l'exception. Ainsi si le bloc remonte une exception qui n'est pas propagé par la méthode il y aura une erreur et il faudra la catcher normalement, par exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

public void method() throws IOException, SQLException { try { method1(); // throws IOException method2(); // throws SQLException method3(); } catch (SQLException e) { log("..."); throw new IOException("SQL Error"); } catch (Throwable t) { // Toutes les exceptions qui arrive ici seront // remonté après l'exécution de ce bloc : log("..."); } }

---

a++

Contre

perte de sémantique;

La sémantique n'est elle pas la voie de la sagesse.

Par contre un truc qui manque peut etre à JAVA c'est la possibilité d'écrire un listener d'exception. Pour les évènements java swing on branche un AWTEventListener sur le toolkit ce qui permet de tracer les actions utilisateurs (pour faire de la recherche en ergonomie, du debuggage, et des graphe fonctionnels... c'est super pratique).

Je crois pas qu'on peut faire pareil avec les Exception. Si c'était possible on pourrait centraliser les log4J (je fais un appel dans le constructeur pour ma part).

Citation:

---

Envoyé par adiGuba

J'opterais plutôt pour ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10

public void method() throws IOException, SQLException { try { method1(); // throws IOException method2(); } throws (Throwable t) { // Toutes les exceptions qui arrive ici seront // remonté après l'exécution de ce bloc : log("..."); } }

---

---

Ouais. Moi j'aime bien l'idée. Ça paraît effectivement plus clair :)
Reste à discuter si « throws » et le bon terme, mais je trouve que l'idée est la bonne.

Tient une idée si throws ne plait pas: watch

Comment ça on risque de confondre avec catch :roll: :mouarf:

Bulbo ;)

Contre.

Je préfère la proposition 7 qui me semble être absolument équivalente (corrigez-moi si je me trompe) :

Code:

---

1 2 3 4 5 6

try { ... } catch (IOException e | SQLException e) { // fault-il mettre des final ? log(...); throw e; }

---

Et que se passe t'il si j'ai ca ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

public void toto() throws IOException { try { something(); } catch(Throwable e) { // e est une IOException, ca va marcher throw e; }   try { somethingelse(); } catch(Throwable e) { // e est pas une IOException throw e; } }

---

Que se passe t'il si n'est pas une IOException ? Le throw n'set pas fait et la méthode continue comme si rien était arrivé ? Il y a une RuntimeException ?

Je ne suis ni convaincu, ni pour.

Je suis pour. Mais c'est vrai que la syntaxe proposée par adiGuba est préférable.

Je vote pour, mais avec la syntaxe d'adiGuba !

super pour la proposition 7 ou d'adiguba.

Autant c'est bien beau d'avoir un langage qui évite les confusions, autant un peu de pragmatisme fait toute la différence dans le succès d'un langage. Voila pourquoi Ruby est maintenant dans le vent.

je suis désolé de contredire ceux qui dénonce un laxisme mais pondre inutilement 10 lignes pour logger une methode, autant dire que je me contente habituellement de catcher Exception et de perdre le type. c'est moins correct mais c'est plus facile a lire, et tous mes collègues approuvent. Pour tous mes projets, je n'ai pas besoin que mon code soit une œuvre d'art de génie logiciel si ca me fait perdre du temps.

du pragmatisme, que diable! nous ne sommes pas des machines.

Contre, le code deviendra incomprehensible

Citation:

---

Envoyé par imad.elghazoini

Contre, le code deviendra incomprehensible

---

en quoi serait-il incomprehensible? au contraire, il y aura moins de fatras.

Citation:

---

Envoyé par bobuse

Encore une fois, le problème ne se poserait pas avec la proposition 7, et ce serait beaucoup moins ambigü !! :roll:

---

Contre cette proposition. La proposition 7 adresse completement ce probleme, et est a mon sens beaucoup plus lisible et compréhensible.

Totalement contre également et totalement pour une solution style proposition 7, qui ne fait ni perdre en lisibilité ni en rigueur.

Contre.

J'ai bien lu tout ce post et ca ne me convint pas.
Ce final là est incompréhensible et je ne doute pas qu'un developpeur débutant se demandera pour quelle raison on ne peut pas "surcharger" ce catch là.

En outre, le besoin me parait $être de simple confort et pas si fondé que cela. Puisqu'en balance, on perd en lisibilité du code, je n'hésite pas. Contre

J'ai eu pas mal de difficulté a comprendre le but de cette modif.
Je pense finalement avoir compris,aujourd'hui une Throwable une fois catcher ne peut etre throw sans etre dans la clause throws de la methode cette proposition le permettrait. On pourrait ainsi catcher ces throwable pour pouvoir faire un traitement et les "throwser" (dsl :) ) sans avoir a polluer la signature de la methode par throws Throwable qui n'a pas de signification precise.

mais imaginons ca :

Code:

---

1 2 3 4 5 6 7 8 9

public maMethode(){ try{ .... }catch(final UneExceptionMetierException e){ log("..."); throw e; } }

---

C'est possible ca ? si oui c'est pas terrible non ?

Citation:

---

Envoyé par FreshVic

C'est possible ca ? si oui c'est pas terrible non ?

---

En fait il faut voir ce catch comme si on ne traitait pas l'exception :

1. On l'attrape.
2. On l'utilise comme on veut (log, ...).
3. Mais on la laisse remonter (comme si on ne l'avait pas catché).

Donc dans ton cas ce serait exactement comme si tu ne traitais pas l'exception :

Code:

---

1 2 3

public void maMethode(){ .... }

---

Donc :

• Soit c'est une unchecked exception et cela fonctionnera (il n'y a pas besoin de la déclarer).
• Soit c'est une checked exception et cela provoquera une erreur du compilateur (car l'exception n'est ni réellement catché ni déclarée dans la cause throws).

a++

Citation:

---

Envoyé par adiGuba

En fait il faut voir ce catch comme si on ne traitait pas l'exception :

1. On l'attrape.
2. On l'utilise comme on veut (log, ...).
3. Mais on la laisse remonter (comme si on ne l'avait pas catché).

Donc dans ton cas ce serait exactement comme si tu ne traitais pas l'exception :

Code:

---

1 2 3

public void maMethode(){ .... }

---

Donc :

• Soit c'est une unchecked exception et cela fonctionnera (il n'y a pas besoin de la déclarer).
• Soit c'est une checked exception et cela provoquera une erreur du compilateur (car l'exception n'est ni réellement catché ni déclarée dans la cause throws).

a++

---

Oui je voulais parler d'une checked exception, ca me rassure.
Merci pour tes lumiere je comprend mieux.

Pas convaincu de l'utilité de ça. Les mauvais point non plus j'en vois, remarque.
a pas voté :aie:

Moi je vosi l'utilité, dans certains cas, il est nécessaire de "faire le ménage" quand tout ne s'est pas passé comme prévu. Ce ménage, habituellement, je le fait comme çà:

Code:

---

1 2 3 4 5 6 7 8 9

try{ un(); deux(); toutOk = true; } finally { if (!toutOk) ménage(); }

---

C'est lisible en soit, mais çà manque par fois, pour les besoins de logging, de la cause de l'échec (sans pour autant avoir envie d'empecher l'échec de remonter, après tout , çà peut être une runtimeException assez critique.

Il a été mentionné les "listener" sur les Exception. Pour avoir activé çà dans mon debugger (pause sur les NoClassDefFoundError pour en trouver l'origine), je vous prie de me croire que l'exécution "normale" de certaines parties de code de la jvm, sont vachement gourmand en exception, tu remplirais ton fichier de logs en une demi-heure :D, donc pas une bonne idée.

Enfin, ce code ne couvre pas exactement la même chose que la proposition 7, en effet si tu ne prend que la 7, tu va devoir à chaque fois te coltinner les Error et les RuntimeExceptions dans ta déclaration ....

Finallement, ce susucre, ne serait que comme un code 'finally' qui n'est exécuté qu'en cas d'exception.

Au fait pourquoi pas cette notation?

Code:

---

1 2 3 4 5 6 7 8 9 10

try { //.... } catch (ExceptionA a){ //.... } finally (Throwable t){ // code en cas d'exception non traitée } finally { // code toujours exécuté }

---

Bonjour,
J'ai voté contre, car cela va apporter plus de confusion qu'autre chose, enfin il me semble. Il a fallu que je la lise plusieurs fois avant de comprendre quelque chose, alors ça ne me parait pas simple à utiliser. De plus même si le multiple catch peut paraitre lourd, cela permet de bien voir les exceptions déclenchées potentielles. Sinon on est obligés d'ajouter du commentaire pour le spécifier, est-ce vraiment plus lisible ?

Par contre j'aime bien l'idée :

Citation:

---

Envoyé par tchize_

Au fait pourquoi pas cette notation?

Code:

---

1 2 3 4 5 6 7 8 9 10

try { //.... } catch (ExceptionA a){ //.... } finally (Throwable t){ // code en cas d'exception non traitée } finally { // code toujours exécuté }

---

---

Mais bon, a moins que je me trompe, mais elle existe dejà sous la forme :

Code:

---

1 2 3 4 5 6 7 8 9 10

try { //.... } catch (ExceptionA a){ //.... } catch(Throwable t){ // code en cas d'exception non traitée } finally { // code toujours exécuté }

---

JHelp

Comme indiqué dans le premier message, le problème avec le catch(Throwable) c'est que tu ne peux pas faire remonter l'exception, sauf en déclarant throws Throwable dans ta méthode...


a++

Je vote pour à 100%, j'ai plein de cas ou je DOIS propager l'exception (pour qu'un rollback de la transaction soit fait par exemple), mais ou je veux pouvoir la logguer avant.

Après si la syntaxe perturbe on peut imaginer:

Code:

---

1 2 3 4 5 6 7 8 9 10

try{     } catch(final Exception e){ log(e); rethrow(e); }

---

Code:

---

1 2 3 4 5 6 7 8 9

try{     } finally(final Exception e){ log(e); }

---

Le deuxième cas risque d'etre compliqué si log(e) balance une exception c'est pas très claire laquelle sera propagée, mais si de toute évidence il faut que ce soit la dernière.

Citation:

---

Envoyé par pala00

Le deuxième cas risque d'etre compliqué si log(e) balance une exception c'est pas très claire laquelle sera propagée, mais si de toute évidence il faut que ce soit la dernière.

---

En fait, ce serai exactement la même règle qu'en cas de levage d'un exception au sein d'un finally standard (comme existant actuellement). L'exception déjà levée disparait au profit de la dernière en date.

Contre, la proposition 7 est suffisante.
L'idée de départ n'est pas inintéressante mais, le réultat est trop ambiguë.