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

**vbrabant** · 16/12/2007, 21h49

Aujourd'hui :

Code :

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

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 :

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

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

**Napalm51** · 19/12/2007, 10h18

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** · 19/12/2007, 10h50

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 :

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

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 :

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

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

**zulot** · 19/12/2007, 11h11

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** · 19/12/2007, 11h19

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.** · 19/12/2007, 11h24

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** · 19/12/2007, 11h36

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** · 19/12/2007, 11h41

pour

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

)

**OButterlin** · 19/12/2007, 12h08

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** · 19/12/2007, 12h13

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

**nicorama** · 19/12/2007, 18h50

Envoyé par 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 :

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

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

+1

**benwit** · 20/12/2007, 10h00

Envoyé par 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 :

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

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

+2

Edité pour modif de syntaxe (cf ci dessous)

**Uther** · 20/12/2007, 11h08

D'ailleurs je viens de faire gaffe que pour ma proposition de syntaxe, il serait même plus logique de faire la déclaration de l'exception en premier:

Code :

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

catch(Exception e : InstantiationException, IllegalAccessException)

Cela ressemblerait plus à ce qui est fait dans un foreach (ca fait trop longtemps que je suis obligé de bosser sur du 1.4, j'avais oublié l'ordre correct):

Code :

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

for (String str : listeDeStrings)

**g_rare** · 08/01/2008, 17h01

Envoyé par Uther

D'ailleurs je viens de faire gaffe que pour ma proposition de syntaxe, il serait même plus logique de faire la déclaration de l'exception en premier:

Code :

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

catch(Exception e : InstantiationException, IllegalAccessException)

Cela ressemblerait plus à ce qui est fait dans un foreach (ca fait trop longtemps que je suis obligé de bosser sur du 1.4, j'avais oublié l'ordre correct):

Code :

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

for (String str : listeDeStrings)

POUR +1

**jproto** · 21/12/2007, 14h44

Je suis pour. Et sans vouloir lever une nouvelle polémique qui semble choquer beaucoup, je dois admettre que personnellement je trouve la notation « | » (façon opérateur logique) tout à fait explicite.

**JHelp** · 19/04/2008, 20h08

Pour, avec la syntaxe d'Uther :

Envoyé par 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** · 21/05/2008, 16h03

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.

**mavina** · 19/12/2007, 13h47

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

Code :

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

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

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

Code :

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

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** · 19/12/2007, 13h54

Envoyé par mavina

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

Code :

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

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

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** · 19/12/2007, 13h56

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.