Discussion :

[adiGuba]

On en revient au même problème, si j'écris

Code :

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

1
2
3
4
catch(SQLException | IOException e)
{
    System.out.println(e.getSQLState());
}

Celà ne compile tout simplement pas ? Celà signifie donc que le compilateur doit vérifier à chaque fois si les exceptions catchées en groupe sont "compatibles" pour l'appel de telle ou telle fonction ?

Donc si je veux faire ca je dois traiter séparément mes exceptions, même si hormis le SQLState je fais exactement le même traitement sur mes exceptions ?

Comme je l'ai dit l'intérêt de cela est de permettre d'éviter de multiplier les try/catch identique avec un code générique. Si tu utilises getSQLState() tu sors du traitement commun et c'est normal que tu utilises un catch spécifique : cela ne rentre pas dans le cadre de cette proposition.

C'est ça ?

Oui. Enfin c'est comme cela que je le comprend.

Dans ce cas, alors, pourquoi ne pas étendre le principe à d'autres types de variables que les exceptions ? Comme ceci :

Je vois déjà nettement moins le besoin de cela... si on a besoin de faire des traitement si spécifique on peut utiliser instanceof :

Code :

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

1
2
3
4
5
6
7
if (maVariable instanceof Ta) {
    Ta a = (Ta) maVariable;
    // ...
} else if (maVariable instanceof Tb) {
    Tb b = (Tb) maVariable;
    // ...
}

a++

[pseudocode]

Comme je l'ai dit l'intérêt de cela est de permettre d'éviter de multiplier les try/catch identique avec un code générique. Si tu utilises getSQLState() tu sors du traitement commun et c'est normal que tu utilises un catch spécifique : cela ne rentre pas dans le cadre de cette proposition.

Dans ce cas la syntaxe utilisée est ambigüe.

Code java :

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

1
2
3
4
5
 
catch(SQLException | IOException e)
{
    e.printStackTrace();
}

Lorsqu'on lit le code, on ne sait pas trop quel est le type de "e" (ce qui est embêtant pour un langage fortement typé):

- Est-ce que "e" est de type IOException ?
- Est-ce que "e" est soit de type IOException soit de type SQLException ?
- Est-ce que "e" est d'un autre type (Exception, Ancetre commun) ?

Je suis du même avis qu'un intervenant précédent pour utiliser une syntaxe plus claire:

Code java :

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

1
2
3
4
5
 
catch(Exception e: SQLException,IOException)
{
       e.printStackTrace();
}

La c'est clair que "e" est du type Exception.
C'est également clair que la classe de "e" est une SQLException ou une IOException.
Le compilateur peut facilement vérifier au moment de la compilation si les type listés sont bien des sous-classes de Exception.


En plus ca reste cohérent avec la syntaxe actuelle:

Code java :

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

1
2
3
4
5
 
catch(Exception e  /*: SQLException,IOException */)
{
       e.printStackTrace();
}

[covao]

Par contre, je préfère que ce soit une virgule au lieu de la barre verticale.

[mathieug92]

Contre.
En fait pas contre cette proposition particulière mais contre l'apparition d'un tas de syntaxe alternatives qui ne seront pas maitrisées par tout le monde et risque de rendre le code immaintenable. Pour avoir eu à maintenir du code Perl, le principe de pouvoir faire la même chose de 100 façon différente n'est pas une très bonne idée.
Après si on conserve les gardes fous nécessaire alors "pourquoi pas".

[deltree]

Simplifier les catchs serait un plus, mais pbm pour la syntaxe (je ne suis pas original )

A la limite avec une virgule. Je n'aime pas l'idée d'ajouter des symbole | ou : dans la syntaxe de déclaration Java, qui sont plus des symbole d'opérateurs.
Ca ferait tendre le langage un peu plus vers C++, et le rendrait moins accessible.

entre parenthèses, le catch(Exception ) n'est pas une alternative viable, il ne faut jamais catcher les exceptions qui n'ont pas à l'être (notamment les Runtime)

Juste pour rire, j'ai pensé à une syntaxe generics:

Code :

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

1
2
3
4
5
6
7
 
try{
  //mon truc qui lance des exceptions.
}catch <T extends Exception super IOException, SQLException>  (T e){
  System.out.println("c'est tout planté");
  return;
}

Vous en pensez quoi?

à ne pas prendre trop sérieusement.
edit: le super n'est pas vraiment correct, puisqu'en fait on "étend" de l'un, ou de l'autre, bref, c'était juste pour faire ressembler à du générique.

[tchize_]

Pour le regroupement, avec précision de l'ancêtre à utiliser. Après avoir, dans une application écrit trois ligne de code dans une méthode puis avoir demandé à mon IDE d'auto générer les catch et terminé avec deux couches imbriquées de try catch finally et une 12aine d'exceptions levée (et oui, quand vous jouez avec des transactions c'est très vite verbeux!) sans possibilité d'ancêtre commun (ceux qui avaient la cahnce d'avoir un ancêtre commun avaient des traitement différents), j'ai terminé avec 3 ligne de buisness code, une 20 aines de lignes de buisness code "nettoyage en cas de problème" et pas moins du reste des 2 pages en code dupliqué / try catch à tout va.


Mais, contre, l'utilisation du |, pour une raison pragmatique, ce caractère nécessite une gymnastique à 2 mains et avec la touche alt-gr sur les claviers belge, alors que la virgule se tappe à une seul doigt Et aussi eu égard au fait que la notation ',' est cohérente avec la notation utilisé en déclaraction de méthode (throws x,y,z) -> catch x,y,z

[JHelp]

Pour, avec la syntaxe d'Uther :

Code :

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

1
2
3
...
catch (Exception e : InstantiationException, IllegalAccessException){
...

Apres , ou | je n'ai pas d'avis. Les deux ce justifient et aucun ne me choque.

JHelp

[_skip]

Pour, pour, pour et encore pour!
Je reprend cet exemple :

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
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
    try
    {
      Class clazz = Class.forName("org.berkeley.Database");
      Constructor constructor =
        clazz.getConstructor(String.class, String.class, String.class);
      return constructor.newInstance(url, username, password);
    }
    catch (InstantiationException e)
    {
      throw new PluginException(e);
    }
    catch (IllegalAccessException e)
    {
      throw new PluginException(e);
    }
    catch (IllegalArgumentException e)
    {
      throw new PluginException(e);
    }
    catch (InvocationTargetException e)
    {
      throw new PluginException(e);
    }
    catch (NoSuchMethodException e)
    {
      throw new PluginException(e);
    }
    catch (SecurityException e)
    {
      throw new PluginException(e);
    }
    catch (ClassNotFoundException e)
    {
      throw new PluginException(e);
    }

Après cela donne :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
    try
    {
      Class clazz = Class.forName("org.berkeley.Database");
      Constructor constructor =
        clazz.getConstructor(String.class, String.class, String.class);
      return constructor.newInstance(url, username, password);
    }
    catch (InstantiationException | IllegalAccessException | IllegalArgumentException | InvocationTargetException | NoSuchMethodException | SecurityException | ClassNotFoundException e)
    {
      throw new PluginException(e);
    }

Et là nous sommes dans un cas ou la gestion de l'exception représente une seule ligne de code! Ce serait marrant si c'était 2-3 voire 10 lignes de codes.

Sérieusement, cette proposition fait partie de mes favorites.

[Ithildine]

Que sera le type de e dans

Code :

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

1
2
3
4
5
try {
    return klass.newInstance();
} catch (InstantiationException | IllegalAccessException e) {
    throw new AssertionError(e);
}

?


J'ai peur que cette syntaxe ne mène à des choses étranges et difficiles à comprendre. Pour cette raison, je serais plutot contre, utiliser une classe mère qui englobe tout ce que l'on veut traiter me semble être la seule façon propre de faire ce genre de chose, simplement à cause du problème de typage de l'exception traitée dans le bloc.

Dans

Code :

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

1
2
3
4
5
6
7
8
9
10
11
try
    {
      Class clazz = Class.forName("org.berkeley.Database");
      Constructor constructor =
        clazz.getConstructor(String.class, String.class, String.class);
      return constructor.newInstance(url, username, password);
    }
    catch (InstantiationException | IllegalAccessException | IllegalArgumentException | InvocationTargetException | NoSuchMethodException | SecurityException | ClassNotFoundException e)
    {
      throw new PluginException(e);
    }

Quelle implémentation du constructeur de PluginException est donc appelée ?

[_skip]

Code :

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

1
2
3
4
5
try {
    return klass.newInstance();
} catch (InstantiationException | IllegalAccessException e) {
    throw new AssertionError(e);
}

Le type de e? Sans doute exception ou throwable. Avec un instanceOf on pourrait connaître et caster e dans son type véritable.

[mavina]

Code :

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

1
2
3
4
5
try {
    return klass.newInstance();
} catch (InstantiationException | IllegalAccessException e) {
    throw new AssertionError(e);
}

Le type de e? Sans doute exception ou throwable. Avec un instanceOf on pourrait connaître et caster e dans son type véritable.

Ok, donc les lignes que tu gagnes dans la proposition tu les perds en tests d'instance...

Comme disait un illustre prof d'info de DUT : "Et voici une belle preuve de la théorie de conservation des emmerdements!"

F.

[tchize_]

Pour avoir écrit du code de traitement d'erreur, dans lequel tu catch 10 exceptions de nature différentes, pour mettre exactement le même code dedans (et je plaisante pas, c'est du log, de la mise en valeur par défaut et du retour, soit en moyenne 5 lignes dupliquées à chaque fois), c'est chiant, illisible et surchargé! Et pour ceux qui disent 'on peut faire un catch sur le type parent commun c'est la même chose...', NON! Ce n'est absolument pas la même chose. Un catch sur le parent commun catch *aussi* ce qu'on ne veux pas catcher, ce qui fait qu'on va quand meme se tapper une tartine de test en dessous pour tout filter et faire des throw de ce dont on avait pas besoin.

Par contre la forme ne me plait pas, elle ne permet pas de typer spécifiquement e, qui peut dans certains cas etre une RuntimeException, dans d'autre une Exception, dans d'autres cas un Throwable.... A l'auteur de décider je trouve.

Le but de ce code n'est pas de faire des catch ou il faut se comporter différement suivant le type, le but est de regrouper les catchs dont le code est identique et pour lequel un type d'exception commun est utilisable, mais ou on ne veux *pas* catcher Tout ce qui correspond au type commun (exemple, on veux catcher 6 RuntimeException)

[_skip]

Ok, donc les lignes que tu gagnes dans la proposition tu les perds en tests d'instance...

Comme disait un illustre prof d'info de DUT : "Et voici une belle preuve de la théorie de conservation des emmerdements!"

F.

Mais non t'as pas compris!
Je disais juste que le type véritable de e serait celui de l'exception qui a été levée.
Je pense que mon premier post avec l'exemple des PluginException montre bien l'intérêt d'une telle chose. Sinon on fait un catch(Exception) et on supprime n'importe quelle erreur ce qui est une bêtise.
D'ailleurs c'est hors sujet mais j'ai toujours trouvé le concept de checked exceptions RI-DI-CU-LE.

[mavina]

Pour avoir écrit du code de traitement d'erreur, dans lequel tu catch 10 exceptions de nature différentes, pour mettre exactement le même code dedans (et je plaisante pas, c'est du log, de la mise en valeur par défaut et du retour, soit en moyenne 5 lignes dupliquées à chaque fois), c'est chiant, illisible et surchargé! Et pour ceux qui disent 'on peut faire un catch sur le type parent commun c'est la même chose...', NON! Ce n'est absolument pas la même chose. Un catch sur le parent commun catch *aussi* ce qu'on ne veux pas catcher, ce qui fait qu'on va quand meme se tapper une tartine de test en dessous pour tout filter et faire des throw de ce dont on avait pas besoin.

Par contre la forme ne me plait pas, elle ne permet pas de typer spécifiquement e, qui peut dans certains cas etre une RuntimeException, dans d'autre une Exception, dans d'autres cas un Throwable.... A l'auteur de décider je trouve.

Le but de ce code n'est pas de faire des catch ou il faut se comporter différement suivant le type, le but est de regrouper les catchs dont le code est identique et pour lequel un type d'exception commun est utilisable, mais ou on ne veux *pas* catcher Tout ce qui correspond au type commun (exemple, on veux catcher 6 RuntimeException)

Encore une fois je ne comprends pas ou est le probleme : dupliquer le code, c'est pas obligatoire, le code dupliqué pouvait facilement se mettre dans une fonction, ce qui facilitait une éventuelle mise à jour / un éventuel débug du code dupliqué (qui ne l'aurait plus été).
Je trouve que cette proposition n'apporte rien ou pas grand chose, mise à part qu'on se demande ce qui va être retourné, ce qui va être catché ou pas, etc etc

Mais non t'as pas compris!
Je disais juste que le type véritable de e serait celui de l'exception qui a été levée.
Je pense que mon premier post avec l'exemple des PluginException montre bien l'intérêt d'une telle chose. Sinon on fait un catch(Exception) et on supprime n'importe quelle erreur ce qui est une bêtise.
D'ailleurs c'est hors sujet mais j'ai toujours trouvé le concept de checked exceptions RI-DI-CU-LE.

C'est bien ce que je dis : sans instanceof, impossible de savoir ce qui a été catché, donc tu en reviens à tester le type de l'excaption apres l'avoir catchée juste pour gagner 3 catch...

F.

[Ithildine]

A mon humble avis, si on veut effectuer le même traitement sur toutes les exceptions que rassemblera cette syntaxe (celle-ci ou une approchante), il va bien falloir trouver un contrat fonctionnel commun à toutes ses exceptions parce que ce sera au final ce que l'on devra manipuler dans le bloc de traitement commun : un truc sur lequel il faudra faire des choses...

Ce que l'on pourra faire comme "trucs" sur cette "chose" dépendra de sa nature... et donc de son type. Il me semble que l'on est donc ramené à trouver un type commun à toutes ces exceptions que l'on rassemble dans cette écriture et donc on est ramené à l'héritage (de type), ce que Java sait déjà faire.

Je me méfie terriblement des facilités d'écriture qui rendent les choses ou moins claires, ou moins lisibles, ou ajoutent encore de la complexité à ce qu'il est souvent préférable de garder un peu verbeux mais au combien plus simple et sans ambiguité.
Quelques secondes de moins à écrire, une vie d'emmerdes en maintenance...

[_skip]

Je ne suis pas d'accord avec vous, il m'arrive très souvent de vouloir réagir à une exception sans pour autant avoir besoin d'informations spécifiques sur l'exception elle-même.

Neuf fois sur dix je me fiche du type de l'exception, je veux juste la catcher pour pouvoir nettoyer derrière moi (par ex : déclencher un rollback) puis ensuite la propager.
Donc ce fameux code de rollback qui se situe dans le bloc catch et qui n'est pertinent que dans le contexte de cette méthode, ça me coûte personnellement de le sortir dans une fonction car si je commence à faire ça je vais avoir autant de méthodes non-réutilisables qui gèrent des exceptions que de méthodes métiers.

Donc la solution actuellement c'est le copier-coller, ce qui n'est pas super. Là ce serait l'occasion d'avoir une véritable solution.

[gexian]

J'ai mis pour car l'idée n'est pas foncièrement mauvaise, même si la syntaxe a un peu trop l'air d'une expression booléenne à mon goût.

Mais bon, beaucoup d'applications ont des exception "maison" qui donnent souvent des choses de ce style :

Code :

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

1
2
3
4
5
try{
    //mon super code
} catch (Exception e){
    throw new MonExceptionTechnique(e);
}

où il n'est pas très important de savoir quel type d'exception a été remontée (car elles ne devraient de toute façon jamais arriver ).

[tchize_]

Encore une fois je ne comprends pas ou est le probleme : dupliquer le code, c'est pas obligatoire, le code dupliqué pouvait facilement se mettre dans une fonction,

La notion de facile est relativement gratuite sans connaitre les détails.
Si ce bloc catch doit manipuler au moins 5 variables différentes, il faudra les passer ladite fonction, pour la lisibilité çà se complique déjà. Ensuite si ta méthode au final ressemble à

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
23
24
25
public UnType maMethode(machin, truc, bidule, chouette) {
...
   Blabla blabla = null;
   Blabla blabla2 = null;
   try{
       blabla  = machine.unTruc(truc.bazar(bidule), chouette);
   } catch (ExceptionType1 e){
       traiteMaMathodeException(e);
   } catch (ExceptionType2 e){
       traiteMaMathodeException(e);
   } catch (ExceptionType3 e){
       traiteMaMathodeException(e);
   } 
 
   try{
       blabla2  = machine.unAutreTruc(truc.bazar(bidule), chouette);
   } catch (ExceptionType1 e){
       traiteMaMathodeException2(e);
   } catch (ExceptionType2 e){
       traiteMaMathodeException2(e);
   } catch (ExceptionType3 e){
       traiteMaMathodeException2(e);
   } 
...
}

Je vois plusieurs problèmes à ces fonctions de traitement d'erreur:
1) elle ne peuvent pas décider conditionnellement si oui ou non il faut poursuivre le traitement (ex: exception && chouette !=null -> on poursuit avec blabla=chouette.getChose())
2) elle ne peuvent pas, en cas de poursuite, changer plusieurs variables locales au bloc appelant (faire sauter un for d'un cran, utiliser une valeur par défaut avant la poursuite du traitement, effectuer un break; du for (note je sais pas si c'est autorisé dans un catch çà). Exemple simple, dans une exception précise sur les transaction de la db, il faut passer par une nouvelle transaction locale à la méthode, noter dans une variable locale qu'on est en transaction locale pour nettoyage dans le finally, çà fait 2 variables à manipuler.
3) il est difficile de leur donner des noms explicite et elles pulluleraient vite.
4) si t'as 10 méthodes objet qui ont deux groupes d'exception à gérer chacune (deux blocs try/catch), çà te rajoute 20 méthodes au noms par toujours net :/
6) pour 5 lignes dans le catch répétées 10 fois dans un try, tu passe de 6 lignes de code (catch + 5 lignes ) à 2 lignes de code, çà t'en fait encore 20 (2*10), alors qu'un catch générique aurait eu seulement 7 lignes (je met les catch générique en 2 lignes, parce que bon, 10 exception, on peut bien les mettre sur 2 lignes :p)

En pratique, si je me suis retrouvé avec des lignes dupliquées dans mes catch, c'est clairement par choix, c'était la moins mauvaise solution.... Alors un truc qui me permettrait d'éclaircir un code si je devais tomber à l'avenir sur ce genre de joyeuseté une nouvelle fois, je suis preneur

[djsnipe]

Et pourquoi ne pas introduire une sur classe d'Exception particulière, qui ait le rôle de représenter toutes les exceptions non runtime pouvant être lancées par le bloc try ?

Ce ne serait finalement pas la seule exception un peu particulière, vu que les RuntimeException existent et on un comportement particulier. Et ça évite d'introduire toute nouvelle syntaxe dans le langage (même si certaines des propositions du topic me conviendraient aussi).

[tchize_]

Et pourquoi ne pas introduire une sur classe d'Exception particulière, qui ait le rôle de représenter toutes les exceptions non runtime pouvant être lancées par le bloc try ?

Ce ne serait finalement pas la seule exception un peu particulière, vu que les RuntimeException existent et on un comportement particulier. Et ça évite d'introduire toute nouvelle syntaxe dans le langage (même si certaines des propositions du topic me conviendraient aussi).

je vois plusieurs problème:

1) les exceptions qu'on voudrait grouper ne doivent alors pas implémenter runtimeException, c'est pas toujours le cas, sourtout quand on hérite de libs tierces sur lesquelles on a peu de controlle
2) çà casse les notions d'héritage en java, on aurait un pseudo classe qui serait "tout sauf..."
3) au final on serati avec 2 groupes, les runtime et les pas runtime, ce qui ne résoud en rien le problème d'origine: traiter plusieurs exceptions (choisies) en un seul bloc.