Discussion :

[Uther]

pourquoi annoncer
catch(MonExcFille1,MonExcFille2 : MonExcMere)
et pas juste les exceptions filles? Je trouve que donner la classe mere ne sert pas à grand chose.

Le compilateur / IDE prendrait automatiquement la classe commune dans la hiérarchie. Donc pas de cast nécessaire et recours aux méthodes "communes" dans le block catch. Ce qui peut donc expliquer l'absence de la définition de cette classe puisque le compilateur saura la déterminer.

Certes le compilateur pourrait prendre automatiquement la première classe mère commune aux exceptions, mais ça voudrait dire que la classe est définie implicitement. En plus du fait que je trouve ça moche, c'est contraire au pricipe Java qui a un typage explicite.

Nulle par en Java une variable n'existe sans que son type soit explicitement spécifié. Pas même dans le foreach (for(String str : listeDeString)) où ce serait tout à fait possible. Je ne pense pas qu'il faille changer ça surtout, pour une modification assez mineure.

Soit j'ai mal compris la proposition, soit je ne comprends pas l'utilité...
pour catcher plusieurs exceptions d'un coup, il y a l'héritage !

L'héritage n'est pas toujours une bonne solution : cf ce post qui l'explique bien

[DrHelmut]

J'avais pas pensé aux exceptions de type NullPointer, IO etc que l'on risque de rameuter avec un simple catch(Exception e)... mais là encore

Au final je dirais ni pour ni contre car ce serait un petit plus pour certains, certes, mais pour ceux qui passent par un IDE comme moi on s'en fout pas mal, à moins de tomber sur une méthode renvoyant pléthore d'exceptions (plus de 4-5, ce qui me parait extremement rare) et là à mon avis y'a un soucis dans la conception de la-dite méthode.

Pour les codeurs "à la mano", c'est un gain assez intéressant mais carrément gadget par rapport aux avancées de Java 5 (foreach/autoboxing/polymorphisme paramétrique => vrai gain en temps de codage ET en lisibilité)

[Uther]

J'avais pas pensé aux exceptions de type NullPointer, IO etc que l'on risque de rameuter avec un simple catch(Exception e)... mais là encore

Au final je dirais ni pour ni contre car ce serait un petit plus pour certains, certes, mais pour ceux qui passent par un IDE comme moi on s'en fout pas mal, à moins de tomber sur une méthode renvoyant pléthore d'exceptions (plus de 4-5, ce qui me parait extremement rare) et là à mon avis y'a un soucis dans la conception de la-dite méthode.

Pour les codeurs "à la mano", c'est un gain assez intéressant mais carrément gadget par rapport aux avancées de Java 5 (foreach/autoboxing/polymorphisme paramétrique => vrai gain en temps de codage ET en lisibilité)

Le temps de codage n'est pas vraiment le problème vu que le copier coller que même notepad gère à la perfection, suffit à régler ça. Par contre c'est vraiment un gain (pas enorme mais appréciable) au niveau de la lisibilité/maintenabilité : ca évite d'avoir à se coltiner plusieurs blocs catch totalement identiques.

- Ca plombe inutilement la lisibilité si le bloc catch fait plus de 3/4 lignes
- Si on fait une modif dans un catch il ne faut pas oublier de la reporter dans les autres.
- Quelqu'un qui ne connait pas encore le code va devoir regarder attentivement pour finalement se rendre compte que les deux catchs sont identiques.

La solution que j'utilise en général est de faire une méthode proccessException(...variables nécéssaires...) appelée par chacun des catch: ca limite la duplication de code a une seule ligne mais ce n'est quand même pas particulièrement élégant.

[cysboy]

Pour, c' est vrai que pour plusieurs exceptions catchées on veuille faire les même s traitements => diminution de code.

[xavlours]

Pour mais ça serait plus joli avec une virgule (quoi je suis chiant ?)

[verbose]

Pour mais ça serait plus joli avec une virgule (quoi je suis chiant ?)

Je suis contre cette proposition, mais avec une virgule à la place du pipe, ça serait déjà mieux

[bgrand]

On peut bien faire un catch(Exception e), mais parfois c'est vraiment trop générique, un niveau intermédiaire entre catcher toutes les exceptions une à une et catcher Exception, ça peut être utile, donc oui.

[®om]

Une fois, en écrivant plein de fois le même traitement pour des exceptions différentes (mais sans liens de parenté direct), je m'étais dit "ça serait vachement bien de faire ça"... Faudrait le proposer...

Jusqu'à ce que je me dise :

Code :

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

1
2
3
4
5
try {
    ...
} catch(ExceptionType1, ExceptionType2 e) {
    e.methode();
}

quel est le type apparent de e?
Throwable? Exception? La plus proche ancêtre commun?

Question à laquelle je n'ai pas trouvé de réponse satisfaisante...

[bgrand]

Effectivement, ça mérite réflexion... Pas non plus encore trouvé de solution qui me plaise tellement...

L'idée qui me dérange le moins (à défaut de me satisfaire...), serait que si on veut catcher plusieurs exceptions à la foi, alors le type de l'exception n'est pas trop important, vu qu'on veut un seul traitement pour toutes.

Par exemple :

Code :

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

1
2
3
4
5
try {
     ...
} catch ({ExceptionA, ExceptionB} e) {
     logger.error(e.getMessage);
}

Dans le cas ci-desssus, le e.getMessage() retournerait les e.getMessage() concaténés de chaque exception catchée, ou un message d'erreur citant les exceptions catchées, ou quelque chose comme ça. Mais le traitement même de l'erreur ne devrait pas dépendre d'un type ou de l'autre, vu qu'on veut un seul catch pour les deux types.

Si on veut pouvoir déterminer le type de e, alors y'a qu'à faire un catch pour chaque type d'exception... et du coup on oublie cette proposition 7.

[Uther]

En fait ce n'est pas l'idée du tout. On ne peut pas et ne pourra pas catcher pas plusieurs exceptions en meme temps. Ce serait totalement incompatible avec la notion actuelle d'exception qui interromp le block d'execution.
Il n'y a donc pas de question a ce poser de concaténation ou autre traitement particulier.

La variable ne ne peux en effet etre du type ExceptionA ou ExceptionB, il faudra obligatoirement un ancêtre commun, ça pourrait être Throwable mais c'est réducteur. Je pense que le plus judicieux serait de spécifier cet ancêtre(cf ma proposition).

[bgrand]

C'est personnel, mais en fait je trouve très bien la situation actuelle. Je ne vois pas tellement de bonne solution pour catcher plusieurs exceptions en même temps. Si on a besoin de le faire, c'est sûrement que dans le try {...}, il y a une bonne quantité de code. Et que donc la gestion des exceptions pourrait être améliorée... On peut même implémenter ses propres exceptions pour ça.

[zegreg]

En fait ce n'est pas l'idée du tout. On ne peut pas et ne pourra pas catcher pas plusieurs exceptions en meme temps. Ce serait totalement incompatible avec la notion actuelle d'exception qui interromp le block d'execution.
Il n'y a donc pas de question a ce poser de concaténation ou autre traitement particulier.

La variable ne ne peux en effet etre du type ExceptionA ou ExceptionB, il faudra obligatoirement un ancêtre commun, ça pourrait être Throwable mais c'est réducteur. Je pense que le plus judicieux serait de spécifier cet ancêtre(cf ma proposition).

Pour ça y a un truc très pratique :

Code :

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

1
2
3
4
 
try{
}catch(Exception e){
}

Pas besoin de nouvelle synthaxe pour ça ...

[Invité1]

Pour. D'accord avec Uther concernant la syntaxe.

[CheryBen]

InstantiationException | IllegalAccessException e

Pour, la syntaxe ne paraît pas si abhérente, on se retrouve avec un object e, et le | qui veut bien dire "ou" indique que e est une instance de InstantiationException ou IllegalAccessException.
Ca permet de faire facilement des traitements génériques, par contre on risque de se retrouver avec des instanceof quelques fois. (si j'ai bien compris le principe)

[Syrion]

Non à cause des développeurs de base qui vont utilsier la syntaxe pour tout catcher et faire des "if(e instanceof ...)"...

Les audits de code que j'ai fait dans mon entreprise et qui ont été fait par des collègues me disent que trop de développeurs vont faire n'importe quoi.

Et puis pour ce qu'on y gagne...

Sun devrait plutôt se poser la question de la rétro-compatibilité et du prix réel à payer si on la cassait pour de vraies features.
Ex : que les types[] et Object[] implémentent réellement Iterable et compagnie, pour que la boucle for(T o:iterable) ne soit plus un hack pour les tableaux.
Autre Ex : que sur les Map "[]" soit équivalent à "get" ( => m.get("clé") serait équivalent à m["clé"]).
Autre Ex : que les closures de Java 7 n'utilisent pas la syntaxe pourrie des closures dites "BGGA" (qui portent donc le nom de ses auteurs, sic), mais plutôt celle de javascript

[ptitbob]

Bonjour,

Le fait est que : un bloc de fonction peux générer plusieurs exceptions (cas général) qui auront en fin de compte le même traitement (propagation d'une exception générale à l'application, traitement de l'erreur de manniere sécurisé, etc...).

Le fait de pouvoir intercepter plusieurs exception en une seule clause except me semble un idée louable si celle-ci nous laisse la possibilité de faire cela :

Code :

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

1
2
3
4
5
6
7
8
try{
} catch (ClassicException | DummyException e) {
// traitement quelconque et commun à plusieurs exceptions
} catch (SpecificException e) {
// traitement spécifique
} catch (Exception e) {
// traitement générique des exceptions non prévues
}

Comme le propose jproto
Cdlt

[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