JDK 7: Proposition 7 : Pouvoir catcher plusieurs exceptions en une fois [Débat]

[vbrabant]

Aujourd'hui :

Code :

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

Demain :

Code :

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

[Napalm51]

Pour, simplement car dans certaines applications, il n'est pas rare de vouloir effectuer le même traitement si l'une ou l'autre des exceptions est lancée, alors que ces dernières ne peuvent être regroupées dans un même type (si ce n'est Exception mais là ...)

[Uther]

Pour le principe mais à condition d'utiliser une autre syntaxe.

Le "|" comme séparateur m'a fait sursauter. Ca me parrait une très mauvaise idée d'utiliser comme séparteur le même symbole qu'un opérateur binaire .
De plus, la classe de l'exception commune "e" n'est pas spécifié ce qui n'est pas naturel dans un catch(et en java tout court même).

Je verais plutôt une syntaxe du style:

Code :

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

édition: en fait faire la déclaration en premier comme dans le foreach serait plus logique:

Code :

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

[zulot]

Je dirais pour, mais en gardant ce qu'a dis Uther et surtout pouvoir aussi utiliser l'ancienne version.

Les deux notations peuvent être pratique.

[Uther]

Evidement il ne faut pas enlever l'ancienne syntaxe, mais de toute façon je ne pense pas qu'aucune des proposition ne soit destinée à remplacer la syntaxe actuelle. Ca serait idiot pour la compatibilté.

L'ancienne notation ne peut pas être enlevée pour 2 raisons:
- Elle permet 2 traitements différents suivant le type de l'exception alors que la nouvelle est justement concue pour éviter cela.
- Il ne faut pas casser la compatibilité, surtout pour ça.

[austin P.]

plutot pour mais avec des réserves sur la syntaxe

cela evite quelques fois d'avoir des catch de 2 km de long et qui repetent la même chose

[adiGuba]

Envoyé par Uther

Pour le principe mais à condition d'utiliser une autre syntaxe.

+1

Le principe est intéressant mais j'aime pas trop la syntaxe

a++

[Gardyen]

pour

mais réserve sur la syntaxe (pourquoi pas une bonne vieille virgule )

[bobuse]

Tout à fait d'accord ! Comme napalm51, ça me gave de devoir dupliquer du code pour gérer de manière identique plusieurs exceptions.

Mais je suis d'accord avec Uther pour dire que le | n'est pas une bonne idée. Je suis d'accord pour la virgule, par contre le "Exception" est implicite à mon avis.

[OButterlin]

Oui, et même restriction pour la syntaxe (plutôt "," que "|")
D'un autre côté, qu'est-il prévu pour la gestion de l'objet exception proprement dit ?
On le traite comme Throwable, Exception ou le premier ancêtre commun ?
Cette dernière pourrait être intéressante...

[romaintaz]

Je suis pour, mais contre cette syntaxe. La virgule me parait pas mal, à défaut de mieux...

[bobuse]

Envoyé par OButterlin

On le traite comme Throwable, Exception ou le premier ancêtre commun ?
Cette dernière pourrait être intéressante...

Effectivement. Dans le cas de l'ancêtre commun, très intéressant, l'explicitation devient nécessaire, par exemple :

Code :

catch (PrinterAbortException, PrinterIOException : PrinterException e){

http://java.sun.com/javase/6/docs/ap...Exception.html

[Uther]

Mais je suis d'accord avec Uther pour dire que le | n'est pas une bonne idée. Je suis d'accord pour la virgule, par contre le ": Exception" est implicite à mon avis.

Il me semble bien qu'il n'y a pas un seul endroit dans la syntaxe Java ou une classe est définie implicitement. C'est à mon humble avis bien plus clair ainsi. On ce retrouve toujours avec une syntaxe déclarative : "MaClasse monObjet" ou on identifie clairement l'objet et sa classe.

Par exemple dans for (listeDeString : String s) {} la variable s est bien définie avec son type alors que on pourrait le déduire de la liste.

[bassim]

je suis pour , pour les mêmes raisons que les autres

[OButterlin]

Ne pourrait-on pas imaginer un groupe d'exceptions plutôt ?

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
public void maMethode1(...) throws GroupeException1
{
   ...
}
 
public void uneAutreMethode(...)
{
   try
   {
      maMethode1(...);
   }
   catch (GroupeException1 e)
   {
...
   }

Vous en pensez quoi ?

[bobuse]

Envoyé par Uther

Il me semble bien qu'il n'y a pas un seul endroit dans la syntaxe Java ou une classe est définie implicitement. C'est à mon humble avis bien plus clair ainsi. On ce retrouve toujours avec une syntaxe déclarative : "MaClasse monObjet" ou on identifie clairement l'objet et sa classe.

Par exemple dans for (listeDeString : String s) {} la variable s est bien définie avec son type alors que on pourrait le déduire de la liste.

Oui oui, tout à fait d'accord. D'ailleurs je te rejoins dans mes messages suivants

[Uther]

OButterlin> Je suis pas sur d'avoir bien compris ton idée. En tout ca ca a l'air bien plus compliqué que la proposition.

[mavina]

Personnellement je suis plutot contre. Le fait est qu'on puisse catcher des exceptions avec un ancetre commun comme ceci :

Code :

1
2
3
 
catch (PrinterAbortException, PrinterIOException : PrinterException e){
}

est la même chose que de catcher dirrectement l'ancetre :

Code :

1
2
catch (PrinterException e){
}

Et si l'on veut en catcher une autre du même ancetre dans un bloc différent, on la catch avant..
Je pense pas que ce soit vital, le systeme actuel est relativement bien fait, ca n'apporte pas énormément.

F.

[bobuse]

Envoyé par mavina

Personnellement je suis plutot contre. Le fait est qu'on puisse catcher des exceptions avec un ancetre commun comme ceci :

Code :

est la même chose que de catcher dirrectement l'ancetre

Bon d'accord. En fait, mon exemple était nul !

Mais revenons à l'idée de départ de catcher deux exceptions, sans catcher leur ancêtre commun. T'es toujours contre ?

[mavina]

Bah le truc c'est que je vois pas quel intêret pourrait avoir cette notation, tu as un exemple concret qu'actuellement en java on ne peut pas faire et qui serait utile ?

F.