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

**djo.mos** · 21/12/2007, 10h33

mouaïii (pour, mais avec reserve).
Comme la majorité: le principe est bon, la syntaxe est un peu à revoir.
En y réfléchissant, j'ai pas trouvé autre chose que le célebrissime virgule. Mais c'est pas très génial non plus

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

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.

**djo.mos** · 21/12/2007, 13h57

Envoyé par djo.mos

mouaïii (pour, mais avec reserve).
Comme la majorité: le principe est bon, la syntaxe est un peu à revoir.
En y réfléchissant, j'ai pas trouvé autre chose que le célebrissime virgule. Mais c'est pas très génial non plus

Encore pour, mais après m'avoir documenté sur la chose, je retire tout ce que je viens de dire sur la syntaxe (le fameux, enfin, le pauvre |): c'est tout à fait compréhensible du moment que c'est réalisé en fait par disjonction de types.

**Uther** · 22/12/2007, 06h38

Je rajouterai contre le | qu'il est incohérent avec le reste de ce qui est fait en JAVA. C'est illogique d'utiliser le | pour les catch si on ne fait pas également:

Code :

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

1
2
3
4
5
class MaClasse implements Serializable & Clonable & Comparable {
    public void maFonction() throws IOException | NullPointerException{
        ...
    }
}

**azalsup** · 26/12/2007, 12h19

ca marche tres bien en python pourquoi pas en java

**djo.mos** · 27/12/2007, 11h49

Bonjour.

Envoyé par azalsup

ca marche tres bien en python pourquoi pas en java

Bah ... peut être que parceque Java est très différent de Python et ce sur tous les plans ?
Bref, ce genre de raisonnement n'est pas valable, sinon, on finirait par avoir une sorte de mélange hétérogène de trucs empreintés à d'autres langages et qui ne collent pas forcément dans la logique de Java.

**sterix92** · 27/12/2007, 17h23

Bonjour,

Le fait d'attraper en une seule ligne plusieurs erreurs me semble être une bonne idée.

Il est eventuellement faisable de faire hériter les erreurs d'une classe abstraite dans le but d'en attraper une seule lorsqu'il est succeptible d'arriver plusieurs erreurs, supposons :

Code :

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

1
2
3
4
5
 
public class abstract Erreur extends IOException {}
 
public class ErreurType1 extends Erreur {}
public class ErreurType2 extends Erreur {}

**djo.mos** · 27/12/2007, 17h34

Bonjour

Envoyé par sterix92

Il est eventuellement faisable de faire hériter les erreurs d'une classe abstraite dans le but d'en attraper une seule lorsqu'il est succeptible d'arriver plusieurs erreurs,

3 choses:
- C'est déjà le cas: Le type Throwable est le parent de toutes les exceptions, quel que'elles soient.
- T'as pas toujours le contrôle dessus: si tu travailles avec une API tièrce (tu le fais à 90% du temps

), tu peux pas leur imposer de lancer tel ou tel type d'exceptions.
- C'est pas très malin d'attraper un type d'esceptions plus général que ceux que tu attends.

**foued_scorpion** · 04/01/2008, 15h09

même remarque que dans la proposition d'un switch sur String.
Je trouvé enuiyeux de faire plusieurs catch et ne pas catcher tous les exceptions dans une seule.

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

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

**denisC** · 11/01/2008, 20h32

Pour le principe, mais effectivement la symtaxe pourrait etre améliorée, en particulier en utilisant l'ancetre des exceptions: cette information est a mon avis essentielle pour le compilateur, a moins de descendre tres bas par défaut (Throwable), mais je trouverai ça une très mauvaise pratique.

**bgrand** · 15/01/2008, 11h40

On peut bien faire un catch(Exception e), mais parfois c'est vraiment trop générique, un niveau intermédiaire entre catcher toutes les exceptions une à une et catcher Exception, ça peut être utile, donc oui.

**®om** · 01/02/2008, 01h01

Une fois, en écrivant plein de fois le même traitement pour des exceptions différentes (mais sans liens de parenté direct), je m'étais dit "ça serait vachement bien de faire ça"... Faudrait le proposer...

Jusqu'à ce que je me dise :

Code :

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

1
2
3
4
5
try {
    ...
} catch(ExceptionType1, ExceptionType2 e) {
    e.methode();
}

quel est le type apparent de e?
Throwable? Exception? La plus proche ancêtre commun?

Question à laquelle je n'ai pas trouvé de réponse satisfaisante...

**bgrand** · 01/02/2008, 08h54

Effectivement, ça mérite réflexion... Pas non plus encore trouvé de solution qui me plaise tellement...

L'idée qui me dérange le moins (à défaut de me satisfaire...), serait que si on veut catcher plusieurs exceptions à la foi, alors le type de l'exception n'est pas trop important, vu qu'on veut un seul traitement pour toutes.

Par exemple :

Code :

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

1
2
3
4
5
try {
     ...
} catch ({ExceptionA, ExceptionB} e) {
     logger.error(e.getMessage);
}

Dans le cas ci-desssus, le e.getMessage() retournerait les e.getMessage() concaténés de chaque exception catchée, ou un message d'erreur citant les exceptions catchées, ou quelque chose comme ça. Mais le traitement même de l'erreur ne devrait pas dépendre d'un type ou de l'autre, vu qu'on veut un seul catch pour les deux types.

Si on veut pouvoir déterminer le type de e, alors y'a qu'à faire un catch pour chaque type d'exception... et du coup on oublie cette proposition 7.

**Uther** · 01/02/2008, 10h38

En fait ce n'est pas l'idée du tout. On ne peut pas et ne pourra pas catcher pas plusieurs exceptions en meme temps. Ce serait totalement incompatible avec la notion actuelle d'exception qui interromp le block d'execution.
Il n'y a donc pas de question a ce poser de concaténation ou autre traitement particulier.

La variable ne ne peux en effet etre du type ExceptionA ou ExceptionB, il faudra obligatoirement un ancêtre commun, ça pourrait être Throwable mais c'est réducteur. Je pense que le plus judicieux serait de spécifier cet ancêtre(cf ma proposition).

**bgrand** · 01/02/2008, 12h43

C'est personnel, mais en fait je trouve très bien la situation actuelle. Je ne vois pas tellement de bonne solution pour catcher plusieurs exceptions en même temps. Si on a besoin de le faire, c'est sûrement que dans le try {...}, il y a une bonne quantité de code. Et que donc la gestion des exceptions pourrait être améliorée... On peut même implémenter ses propres exceptions pour ça.

**jollyy** · 05/02/2008, 11h10

Je suis plutôt pour, mais je crois je la vrai solution au merdier serait de changer la hierarchie des class d'Exception.

Throwable devrait être unchecked.
Error extends throwable devrait contenir toutes les erreur découlant d'erreurs de programmation (NullPointerException --> NullPointerErrorr, etc...) et non pas de circonstance non controllées par le programmeur.
Exception devrait devenir unchecked (comme l'est RuntimeException).
RuntimeException devrait être supprimée et une nouvelle class CheckedException devrait être créée et utilisée avec modération.

Ceci enleverait 90% du code de traitement des erreur sans en réduire la fonctionnalité (qui peut me dire la dernière fois qu'il a codé autre chose qu'un rethrow ou un log de l'erreur).

**adiGuba** · 05/02/2008, 11h19

Envoyé par jollyy

Throwable devrait être unchecked.

Throwable ne peut pas être unchecked, car cela impliquerait que toutes les classes filles serait unchecked, et donc qu'il n'y aurait plus de checked-exception...

Envoyé par jollyy

Error extends throwable devrait contenir toutes les erreur découlant d'erreurs de programmation (NullPointerException --> NullPointerErrorr, etc...) et non pas de circonstance non controllées par le programmeur.

Ca c'est ce que font les RuntimeException ! Les Errors concernent justement toutes les circonstances non controllées par le développeur...

Envoyé par jollyy

Exception devrait devenir unchecked (comme l'est RuntimeException).
RuntimeException devrait être supprimée et une nouvelle class CheckedException devrait être créée et utilisée avec modération.

Même remarque que pour Throwable : cela reviendrait à dire que toutes les classes filles sont unchecked...

Envoyé par jollyy

Ceci enleverait 90% du code de traitement des erreur sans en réduire la fonctionnalité (qui peut me dire la dernière fois qu'il a codé autre chose qu'un rethrow ou un log de l'erreur).

Je ne vois pas en quoi cela enlèverait 90% des codes de traitements...

Par contre cela casserait toute compatibilité à cause de la réorganisation de l'héritage des exceptions...

a++

**rXpCH** · 05/02/2008, 11h47

Je suis totalement pour, il arrive qu'on ets plusieurs chose à catch... Mais le "|" m'as un peu choquer au début ^^ peros je préférerais un "," enfin bref...