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

[jproto]

Envoyé par pcaboche

Pas de hiérarchie commune ? Moi qui croyais que toutes les exceptions étaient des sous-classes de Exception et que quasiment tout en Java était une sous-classe d'Object (sauf les types de base: int, char...). On m'aurait menti ?

Ce que je voulais dire par "Pas de hiérarchie commune" c'est aucune hiérarchie spécialisée. Il est évident que tout objet hérite de Object, et que toute exception hérite de Exception, mais sincèrement, il y a nombre de cas dans lesquels ce n'est pas exploité.
Nombre de traitements d'exceptions se contentent d'appliquer un traitement "fonctionnel" à un nombre donné d'exceptions sans récupérer quoi que ce soit de l'objet Exception réellement émis. (sans compter les exception simplement ignorées ou relayées, mais ce n'est pas le sujet ici)

[adiGuba]

Envoyé par pcaboche

Oui, et dans ce cas, e est de quel type ? IOException ou SQLException ? Si je fais Ctrl+Espace, comment l'IDE fait pour savoir de quel type est e et quels choix propose-t-il pour l'auto-complétion ?

Perso je vois "e" comme une Exception ou plus généralement un Throwable, mais la proposition d'Uther en premier page est très intéressante puisqu'elle permet de spécifier un type parent...

Dans les deux cas tu aurais accès à toutes les méthodes standard des exceptions ce qui est amplement suffisant dans la plupart des cas...

Maintenant si tu as besoin d'utiliser des méthodes spécifiques à l'un ou l'autre des exceptions cela signifie que tu n'as pas un traitement commun et donc il faut utiliser deux catch !

Envoyé par pcaboche

En effet, rendez-vous compte: on déclare une variable qui, dans le code, peut-être tantôt d'un type, tantôt d'un autre. C'est du délire ! Au moins dans la version "crade", quand on déclare une variable, on connaît son type...

Je ne comprend pas trop cette remarque : je ne vois pas pourquoi le type de l'exception changerait

a++

[mavina]

Envoyé par pcaboche

Mon Dieu mais quelle horreur !

Contre à 2^1024 %, pour la raison invoquée ici :



Que se passe-t-il quand on a des Exceptions de type très différents ? Tout ce que le compilateur peut faire, c'est rechercher un ancêtre commun à
toutes les exceptions (au pire: Exception, qui est la classe de base de toutes les exceptions) et dans ce cas là, la proposition n'a strictement aucun intérêt.

Sinon, en C# on peut faire ça (*) :

Code :

C'est un peu dans l'esprit de départ, non ? (appliquer un même traitement à toute une famille d'exceptions, mais pouvoir appliquer des traitements spécifiques sur certains types d'exceptions) Et ça reste relativement lisible.

Il me semble qu'il est possible de faire sensiblement la même chose en Java (mais je ne sais plus comment).


(*) non, ce n'est pas un troll mais un élément de comparaison. On n'est pas dans la taverne.

Tu veux surement parler de instanceof :

Code :

if(e instanceof Exception1 || e instanceof Exception2)

F.

[mavina]

Envoyé par adiGuba

Je ne comprend pas trop cette remarque : je ne vois pas pourquoi le type de l'exception changerait

a++

Admétons :

Code :

1
2
3
4
5
6
7
8
 
try
{
 //...
}catch(IOException | SQLException e)
{
    System.out.println(e.getSQLState());
}

Si on rentre dans le catch suite à un IOException, que fait java ?

F.

[bulbo]

Envoyé par mavina

Admétons :

Code :

Si on rentre dans le catch suite à un IOException, que fait java ?

F.

Je pense que ça ne compile pas tout simplement.. "e" sera probablement de type exception.

Avoir un catch commun est intéressant pour faire des actions communes. Mais c'est vrai que dans ce cas ce n'est pas très efficace autant avoir 2 catchs et éventuellement une méthode pour les actions communes. Surtout que la résolution de la signature d'une méthode se faisant a la compile, il est inutile de tenter une ruse avec la surcharge..

Bulbo

[jproto]

Envoyé par mavina

Admétons :

Code :

Si on rentre dans le catch suite à un IOException, que fait java ?

F.

Je voyais la réponse ici :

Envoyé par adiGuba

Maintenant si tu as besoin d'utiliser des méthodes spécifiques à l'un ou l'autre des exceptions cela signifie que tu n'as pas un traitement commun et donc il faut utiliser deux catch !

Si tu fais appel à quoi que ce soit de spécifique à un objet d'exception en particulier, il est anormal d'utiliser ce type de syntaxe.
A mon avis, cela mérite une nouvelle exception.

[mavina]

Envoyé par bulbo

Je pense que ça ne compile pas tout simplement.. "e" sera probablement de type exception.

Avoir un catch commun est intéressant pour faire des actions communes. Mais c'est vrai que dans ce cas ce n'est pas très efficace autant avoir 2 catchs et éventuellement une méthode pour les actions communes. Surtout que la résolution de la signature d'une méthode se faisant a la compile, il est inutile de tenter une ruse avec la surcharge..

Bulbo

Mais généralement on est dans ce cas, on n'a que très rarement deux exceptions de types quasiment égaux, et dans ce cas autant catcher l'exception mère la plus proche des exceptions de types quasiment égaux...

Je ne vois pas où l'intêret de cette syntaxe peut se révèler parceque soit on catch deux exceptions proches dans le même bloc ce qui revient à catcher l'exception mere, soit on catch deux exceptions très "lointaines" dans deux blocs, ce que l'on fait déjà dans notre code actuellement...


F.

[mavina]

Envoyé par jproto

Si tu fais appel à quoi que ce soit de spécifique à un objet d'exception en particulier, il est anormal d'utiliser ce type de syntaxe.
A mon avis, cela mérite une nouvelle exception.

On est d'accordsur ce point. Alors si malgré toute la logique que tu as mise dans ta phrase, je décide quand même d'écrire ceci, que se passe-t-il ?

F.

[dingoth]

Dans ce cas d'utilisation, je ne vois qu'une possibilité, moi : considérer e comme une Exception.

Code :

1
2
3
4
5
6
7
8
try {
  ...
} catch (IOException | SQLException e) {
  e.getSQLState(); // ne compile pas car e est déclaré du type Exception et non de ses enfants.
  log.info(e);
} catch (Exception e) {
  log.error(e);
}

Ce code permet simplement d'éviter d'écrire un instanceof ou de regrouper deux catch dont la fonctionnalité est identique et n'utilise que les méthodes d'Exception.

Le multiple-catch doit être la contraction de ceci et uniquement ceci :

Code :

1
2
3
4
5
6
7
8
9
try {
  ...
} catch (IOException e) {
  log.info(e);
} catch (SQLException e) {
  log.info(e);
} catch (Exception e) {
  log.error(e);
}

Si on veut des traitements différents en fonction du type d'exception, c'est simple : la solution existe. Ici si la proposition ne rejoint pas ce que j'ai écrit, je ne le comprends pas, ni elle, ni son intérêt.

[vbrabant]

Envoyé par dingoth

Le multiple-catch doit être la contraction de ceci et uniquement ceci :

Code :

Si on veut des traitements différents en fonction du type d'exception, c'est simple : la solution existe. Ici si la proposition ne rejoint pas ce que j'ai écrit, je ne le comprends pas, ni elle, ni son intérêt.

C'est exactement l'esprit de cette solution. Ne pas devoir, dans chaque catch, répeter le même code.

Vincent

[dingoth]

Eh bien oui, la variable récupérée doit donc être de type Exception (ou au moins le plus grand ancêtre commun).

Je ne comprends pas alors la réaction de Mavina : l'exception attrapée ne peut pas avoir de méthode getSQLState() sans être castée.

[mavina]

Envoyé par dingoth

Eh bien oui, la variable récupérée doit donc être de type Exception (ou au moins le plus grand ancêtre commun).

Je ne comprends pas alors la réaction de Mavina : l'exception attrapée ne peut pas avoir de méthode getSQLState() sans être castée.

Donc si tu récupères ta variable en tant qu'une Exception, on est d'accord que coté compilateur, c'est comme ci tu faisais un

Code :

catch(Exception e)

Alors quel intérêt ?

De plus tu parles de cast, il faudrait savoir : tu peux pas caster l'exception SQLException | IOException sans faire un instanceof pour être sur que c'est bien l'une ou l'autre...

F.

[bulbo]

Envoyé par mavina

Donc si tu récupères ta variable en tant qu'une Exception, on est d'accord que coté compilateur, c'est comme ci tu faisais un

Code :

catch(Exception e)

Alors quel intérêt ?

Un petit exemple de l'intérêt de la chose:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
try
{
....
}
catch (IOException | SQLException e)
{
  // Traitement d'une exception lors de l'accès a une DB par exemple
}
catch(Exception e)
{
  // Traitement d'un cas d'exception inattendu et peut-être fatale a l'application
}

J'ai eu ce cas dans un de mes codes ou j'ai du traiter 4 exceptions d'une certaine manière, une cinquième d'une autre et finalement un catch Exception pour le reste avec un sixième traitement.

Bulbo

[adiGuba]

Envoyé par mavina

Donc si tu récupères ta variable en tant qu'une Exception, on est d'accord que coté compilateur, c'est comme ci tu faisais un

Code :

catch(Exception e)

Alors quel intérêt ?

Non ce n'est pas la même chose : avec un catch(Exception) tu attrapes toutes les exceptions possibles et imaginables, y compris les RuntimeExceptions qui ne devraient généralement pas être traités...

De plus cela peut "cacher" d'autres exceptions : le compilateur ne t'avertira pas en cas où il y a d'autre exception "non traité" (que tu pourrais vouloir traiter différemment) puisque tu les traites toutes...

On passe d'une gestion fine (en cas d'IOException ou de SQLException, je fais ceci) à un traitement global pour toutes les exceptions...


Concretement :

Code :

1
2
3
catch (IOException | SQLException e) {
    // traitement
}

Est plutôt strictement équivalent à :

Code :

1
2
3
4
5
catch (IOException e) {
    // traitement
} catch (SQLException e) {
    // traitement
}

(sans le double traitement bien sûr)



Cela peut particulièrement être utile avec des APIs utilisant de multiples exceptions (comme c'est le cas pour la reflection), puisque cela te permet de regrouper les exceptions dans des groupes plus généraux (les erreurs de config, les erreurs de dev, les erreurs "rattrapables", ...).



a++

[zegreg]

Envoyé par jproto

J'y vois tout de même l'intérêt de pouvoir regrouper le traitement de plusieurs exceptions qui n'auront pas de hiérarchie commune, mais qui ferons l'objet d'un même traitement.

oui, certes! Mais lit peut-être ce que je remet en cause !!!... L'intétêt d'avoir une syntaxe spéciale est justement de pouvoir catcher des exceptions qui ne sont pas communes. Faire un traitement pour des exceptions avec des ancêtres communs c'est déjà possible, pas besoin d'un débat pour cela...

[mavina]

Envoyé par adiGuba

Non ce n'est pas la même chose : avec un catch(Exception) tu attrapes toutes les exceptions possibles et imaginables, y compris les RuntimeExceptions qui ne devraient généralement pas être traités...

De plus cela peut "cacher" d'autres exceptions : le compilateur ne t'avertira pas en cas où il y a d'autre exception "non traité" (que tu pourrais vouloir traiter différemment) puisque tu les traites toutes...

On passe d'une gestion fine (en cas d'IOException ou de SQLException, je fais ceci) à un traitement global pour toutes les exceptions...


Concretement :

Code :

Est plutôt strictement équivalent à :

Code :

(sans le double traitement bien sûr)



Cela peut particulièrement être utile avec des APIs utilisant de multiples exceptions (comme c'est le cas pour la reflection), puisque cela te permet de regrouper les exceptions dans des groupes plus généraux (les erreurs de config, les erreurs de dev, les erreurs "rattrapables", ...).



a++

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

Code :

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 ?

F.

[dingoth]

Selon ma vision de la chose, je réponds oui à tes trois questions.

[zegreg]

Pourquoi pas une syntaxe qui se rapprocherait du switch case adapté pour le catch ... car perso pas vraiment convaincu par les syntaxes proposées.

Code :

1
2
3
4
5
6
7
8
9
10
 
try{
 
} 
catch(ExceptionA e) :
catch(ExceptionB e):
    traitement
    break;
catch(ExceptionC e):
...

Bon mon exemple n'est absolument pas au point, mais l'esprit y est , et ça permettrait d'éviter une syntaxe avec l'opérateur | qui a un sens déjà bien précis


Ça ne résous pas les problèmes cités ci-dessus (utilisation de méthodes spécifiques), mais ça je crois pas que ce sera possible dans quelconque syntaxe proposée...

[Ricky81]

Envoyé par mavina

Mais généralement on est dans ce cas, on n'a que très rarement deux exceptions de types quasiment égaux, et dans ce cas autant catcher l'exception mère la plus proche des exceptions de types quasiment égaux...

En faisant comme ca, tu imposes un traitement commun à toute une hiérarchie, y compris des classes d'exceptions que tu serais amené à créer par la suite. (on en revient alors au problème du catch (Exception) déjà évoqué).

[pcaboche]

Envoyé par adiGuba

Perso je vois "e" comme une Exception ou plus généralement un Throwable, mais la proposition d'Uther en premier page est très intéressante puisqu'elle permet de spécifier un type parent...

En intégrant la proposition d'Uther (avait pas vu...) et en spécifiant un peu :

Code :

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
try
{
    ...
}
catch (T1 | T2 | T3 a : Ta)
{
  // - Ta doit être compatible avec les types T1, T2 et T3
  // - a est de type Ta
  // - la portée de a se limite à ce bloc
  //
  // - Ta DOIT être spécifié pour faciliter la lecture du code
  //     ainsi que le travail du compilateur
 
  //  LÀ, AU MOINS, ON CONNAIT EXPLICITEMENT LE TYPE DE a !!!
 
}
catch (T4 | T5 b : Tb)
{
  // - Tb doit être compatible avec les types T4 et T5
  // - b est de type Tb
  // - la portée de b se limite à ce bloc
  //
  // - Tb DOIT être spécifié pour faciliter la lecture du code
  //     ainsi que le travail du compilateur
 
  //  DE MÊME, ICI ON CONNAIT EXPLICITEMENT LE TYPE DE b !
 
}
catch (_)
{
  // Les autres exceptions (ce bloc est facultatif)
}

C'est ça ?


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

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
match (maVariable)
with (T1 | T2 | T3 a : Ta)
{
   // - Ta doit être compatible avec les types T1, T2 et T3
   // - a est de type Ta
   // - la portée de a se limite à ce bloc
}
with (T4 | T5 b : Tb)
{
   // - Tb doit être compatible avec les types T4 et T5
   // - b est de type Tb
   // - la portée de b se limite à ce bloc
}
with (_)
{
   // Les autres types d'objets
}

Je pense que vous aurez tous reconnu le langage qui a inspiré cette syntaxe (sauf que l'original est mieux, mais il faut bien essayer d'adapter aux spécificités de Java...).