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

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

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 :

for (String str : listeDeStrings)

[bmoussaud]

Pour. Effectivement la syntaxe est peut etre à revoir.
Mes souvenirs de C++ commence à être un peu flou,mais je crois me souvenir que le C++ utilise le séparateur ',' depuis le début ? non ?

[ludosoft]

Pour, mais en changeant "|" pas une ",".

[Traroth2]

Pour. J'attends ça depuis longtemps.

[DrHelmut]

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 !

[cysboy]

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

[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é)

[xavlours]

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

[verbose]

Envoyé par xavlours

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

[Uther]

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

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.

[pierreact]

Je suis d'accord avec ce changement et, contrairement a d'autre, je n'ai rien du tout contre la syntaxe.... apres tout, | veut dire "ou"

[vbrabant]

Envoyé par pierreact

Je suis d'accord avec ce changement et, contrairement a d'autre, je n'ai rien du tout contre la syntaxe.... apres tout, | veut dire "ou"

Exactement. Un petit truc amusant. Durant le BOF quelqu'un a demandé pour quoi le | et pas le ||.

Vincent

[kpouer]

Contre pour ma part, si les différentes Exceptions ont une classe parente commune autre que Exception, on catche cette classe mère tout betement, sinon de quel type sera l'exception catchée ? Le compilateur le détermine au pif ?
Et si les 2 exceptions n'ont rien de commun, a ce moment ca n'a pas vraiment de sens de les catcher explicitement, autant catcher Exception

[Ricky81]

Envoyé par Uther

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.


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

Lorsque je dis que le compilateur va prendre la première classe commune, c'est essentiellement pour illustrer comment les IDE vont fournir une complétion dans le bloc catch => liste des méthodes communes (et donc implicitement celles de la classe mère commune). Ca ne veut toujours pas dire qu'on manipule cette classe "mère" (cf. deuxième partie de mon message).

Envoyé par kpouer

Contre pour ma part, si les différentes Exceptions ont une classe parente commune autre que Exception, on catche cette classe mère tout betement, sinon de quel type sera l'exception catchée ? Le compilateur le détermine au pif ?
Et si les 2 exceptions n'ont rien de commun, a ce moment ca n'a pas vraiment de sens de les catcher explicitement, autant catcher Exception

Ca me rend malade de voir des catch Exception non justifiés et foutre par conséquent la merde quand à l'évolutivité du code (imagine que tu modifies une méthode appelée dans le bloc try et qu'elle déclare une nouvelle exception dans la clause throws, tu n'as même pas d'erreur de compilation qui t'alerte du fait que tu as un nouveau cas à gérer, pas cool si justement cette exception était à propager)

Encore une fois, ce n'est que du sucre syntaxique. Le compilateur ne va rien faire d'autre que de traduire cela en plusieurs blocs catch comme s'ils avaient été écris. A aucun moment il n'y aurait de catch (ExceptionMere) généré.

[the-gtm]

Et là le compilateur il dit quoi?

Code :

1
2
3
4
5
6
7
8
9
10
11
catch(MonExcFille1,MonExcFille2 e) {
  processException(e);
}
 
public void processException(MonExcFille1 e) throws Throwable {
  // ...
}
 
public void processException(MonExcFille2 e) {
  // ...
}

Il dit que les Throwable doivent être déclarées ou catchées ou pas?

Et dans ce cas là? Est ce qu'il renvoie une erreur parce que Throwable n'est jamais lancée?

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
catch(MonExcFille1,MonExcFille2 e) {
  try {
    processException(e);
  } catch (Throwable t) {
    //...
  }
}
 
public void processException(MonExcFille1 e) throws Throwable {
  // ...
}
 
public void processException(MonExcFille2 e) {
  // ...
}

Comme dit Uther, tout variable doit avoir un type déclaré.

[Ricky81]

Il dit erreur de compilation processException est susceptible de lancer un Throwable pour MonExcFille1, comme si tu écrivais

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
catch(MonExcFille1 e) {
  processException(e);
}
catch(MonExcFille2 e) {
  processException(e);
}
 
public void processException(MonExcFille1 e) throws Throwable {
  // ...
}
 
public void processException(MonExcFille2 e) {
  // ...
}

Je crois que tu cherches la petite bête, et je ne vois pas en quoi la déclaration d'un type apporterait une solution.

[the-gtm]

Et avec le try catch imbriqué, il te donne aussi une erreur (Throwable is never thrown)...

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
catch(MonExcFille1 e) {
  try {
    processException(e);
  } catch (Throwable t) {
    //...
  }
}
catch(MonExcFille2 e) {
  try {
    processException(e);
  } catch (Throwable t) {
    //...
  }
}
 
public void processException(MonExcFille1 e) throws Throwable {
  // ...
}
 
public void processException(MonExcFille2 e) {
  // ...
}

C'est pas chercher la petite bête, un langage a une définition formelle. Pour le Java c'est (entre autres choses) d'être fortement typé. Le typage sert par exemple pour résoudre les méthodes appelées, il est aussi utilisé pour vérifier les casts que tu fais, ce code ne compile donc pas:

Code :

1
2
String a = "";
Double b = (Double) a;

Est ce que ce code compilerait ?

Code :

1
2
3
catch(MonExcFille1,MonExcFille2 e) {
  MonExcFille1 ee = (MonExcFille1) e;
}

[Gargamail]

Contre.
À mon avis,

• soit il y a une classe/interface mère pour les exceptions qu'on veut regrouper,
• soit les exceptions sont mal définies et cette classe/interface mère devrait exister.

[Uther]

Envoyé par vbrabant

Exactement. Un petit truc amusant. Durant le BOF quelqu'un a demandé pour quoi le | et pas le ||.

Vincent

Je me suis également posé cette question avant d'arriver à la conclusion que aucun des deux n'était vraiment à sa place dans un catch.

C'est vrai qu'il y a une notion de "ou" et que "||" peut sembler plus adapté car il fait un ou logique. Mais "|" et "||" sont tous deux en JAVA des opérateurs, ce qui signifie qu'ils sont sensés transformer leurs opérandes en un résultat qui sera traité.

Au début je me suis dit ok on peut se dire que le "|" entre 2 classes retourne le premier parent commun donc IOException|SQLException vaut Exception. Dans ce cas là "|" est en effet plus adapté que "||" qui retourne un booleen quels que soient ses opérandes.

Mais ici "|" n'est clairement pas un opérateur. En effet tout l'interet de cette proposition c'est que catch(IOException | SQLException e) ne doit pas être équivalent à catch(Excpetion e).
Donc "|" a bien une effet de séparateur, pas d'opérateur. Dans le role du séparateur, la "," ou le ";" sont tout a fait indiqués plutot que donner a "|" un role de séparateur dans un catch et d'opérateur partout ailleurs.