Discussion :

[kpouer]

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

Code :

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

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 ?

[jproto]

Je ne suis ni convaincu, ni pour.

[Uther]

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

[n!co]

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

[gokud-o-matic]

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.

[imad.elghazoini]

Contre, le code deviendra incomprehensible

[gokud-o-matic]

Contre, le code deviendra incomprehensible

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

[denisC]

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

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

[chtig]

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

[Bollagain]

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

[FreshVic]

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 :

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

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 ?

[adiGuba]

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 :

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

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++

[FreshVic]

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 :

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

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.

[kisame]

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

[tchize_]

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 :

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

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 , 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 :

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

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é
}

[JHelp]

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 :

Au fait pourquoi pas cette notation?

Code :

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

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 :

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

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

[adiGuba]

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++

[pala00]

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 :

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

1
2
3
4
5
6
7
8
9
10
 
 
try{
 
 
}
catch(final Exception e){
   log(e);
   rethrow(e);
}

Code :

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

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.

[tchize_]

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.

[gexian]

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