Discussion :

[jproto]

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]

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 !

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]

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 :

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
try
{
   ...
 
}
catch (Exception e)
{
  ExceptionA a = e as ExceptionA;
  if (a != null)
  {
     //  cette portion de code est exécutée, ssi e peut être casté en ExceptionA
     ...
  }
 
  if (e is ExceptionA || e is ExceptionB)
  {
     // exécuté si e peut être casté en ExceptionA ou ExceptionB
  }
 
}

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 :

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

if(e instanceof Exception1 || e instanceof Exception2)

F.

[mavina]

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

a++

Admétons :

Code :

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

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]

Admétons :

Code :

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

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.

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]

Admétons :

Code :

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

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.

Je voyais la réponse ici :

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]

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]

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 :

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

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 :

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

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]

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

Code :

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

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.

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]

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 :

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

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]

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 :

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

catch(Exception e)

Alors quel intérêt ?

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

Code :

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

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]

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 :

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

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 :

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

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

Est plutôt strictement équivalent à :

Code :

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

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]

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]

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 :

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

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

Est plutôt strictement équivalent à :

Code :

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

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++

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

Code :

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

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 :

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

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]

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]

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 :

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

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
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...).