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

**adiGuba** · 19/12/2007, 13h46

Envoyé par mavina

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 ?

Cela permettrait de déterminer un comportement différent pour des exceptions différentes, par exemple pour les englober dans une exception commune, par exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
	public static void method() throws MyException {
		try {
 
			// Code pouvant renvoyer des IOException / SQLException
 
		} catch (IOException e) {
			throw new MyException("erreur method", e);
		} catch (SQLException e) {
			throw new MyException("erreur method", e);
		}
	}

On pourrait utiliser directement ceci (exemple avec la syntaxe de Uther que je trouve bien plus clair) :

Code :

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

1
2
3
4
5
6
7
8
9
	public static void method() throws MyException {
		try {
 
			// Code pouvant renvoyer des IOException / SQLException
 
		} catch (IOException, SQLException : Exception e){
			throw new MyException("erreur method", e);
		}
	}

Tu vas me dire on peut faire ceci :

Code :

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

1
2
3
4
5
6
7
8
9
	public static void method() throws MyException {
		try {
 
			// Code pouvant renvoyer des IOException / SQLException
 
		} catch (Exception e){
			throw new MyException("erreur method", e);
		}
	}

Oui mais ce n'est pas exactement la même chose : ici tu vas également récupérer toutes les RuntimeExceptions or ce n'est pas forcément voulu car elle représente plus une erreur dans le programme et qu'on aurait voulu les laisser remonter normalement...

En fait actuellement il faudrait faire ceci afin d'ignorer les RuntimeException :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
	public static void method() throws MyException {
		try {
 
			// Code pouvant renvoyer des IOException / SQLException
 
		} catch (RuntimeException e) {
			throw e; // on remonte les RuntimeExceptions
		}catch (Exception e){
			throw new MyException("erreur method", e);
		}
	}

De même cette solution n'est plus possible si tu as plusieurs types d'exception à gérer différemment :

Code :

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

1
2
3
4
5
6
7
8
9
		try {
 
			// ...
 
		} catch (SQLException, IOException : Exception e){
			// ... exceptions dû à une ressource inexistante ...
		} catch (IllegalArgumentException, IllegalStateException : Exception e){
			// ... exception dû à une mauvaise utilisation ...
		}

a++

**bobuse** · 19/12/2007, 16h06

Envoyé par adiGuba

Tu vas me dire on peut faire ceci :

Code :

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

1
2
3
4
5
6
7
8
9
	public static void method() throws MyException {
		try {
 
			// Code pouvant renvoyer des IOException / SQLException
 
		} catch (Exception e){
			throw new MyException("erreur method", e);
		}
	}

Oui mais ce n'est pas exactement la même chose : ici tu vas également récupérer toutes les RuntimeExceptions or ce n'est pas forcément voulu car elle représente plus une erreur dans le programme et qu'on aurait voulu les laisser remonter normalement...

En fait actuellement il faudrait faire ceci afin d'ignorer les RuntimeException :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
	public static void method() throws MyException {
		try {
 
			// Code pouvant renvoyer des IOException / SQLException
 
		} catch (RuntimeException e) {
			throw e; // on remonte les RuntimeExceptions
		}catch (Exception e){
			throw new MyException("erreur method", e);
		}
	}

De même cette solution n'est plus possible si tu as plusieurs types d'exception à gérer différemment :

Code :

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

1
2
3
4
5
6
7
8
9
		try {
 
			// ...
 
		} catch (SQLException, IOException : Exception e){
			// ... exceptions dû à une ressource inexistante ...
		} catch (IllegalArgumentException, IllegalStateException : Exception e){
			// ... exception dû à une mauvaise utilisation ...
		}

Merci pour cet exemple qui tient bien la route

Je pense que c'est plus parlant comme ça.

Je compatis avec bulbo, car moi aussi dans une grosse appli, je gère plusieurs classes d'exceptions à un niveau différent, et ça demande des catch à rallonge, ce qui est pour moi une grande source de bugs

**Uther** · 19/12/2007, 14h19

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

Pour l'exemple que tu donnes c'est en effet la même chose, vu que PrinterAbortException et PrinterIOException sont les 2 seules classes filles de PrinterException.

Par contre dans ce cas:

Code :

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

catch(ClassCastException, NullPointerException : RuntimeException e){...}

Cela permettrait de catcher les erreurs de classcast et nullpointer mais pas les autres RuntimesException comme les divisions par 0.

**bulbo** · 19/12/2007, 13h42

Pour,

mais comme beaucoup la syntaxe

Mavina > Sans parler de l'ancêtre et de la propal du forum, ça peut éviter de dupliquer du code, ce qui est toujours un gain intéressant (coding + maintenance)

J'ai le cas dans une grosse appli: j'ai un méthode qui lance un long processus et au cours de ce processus de nombreuses exceptions peuvent interrompre le tout.
Certaines sont simplement redirigées vers l'utilisateur (via des dialogues), certaines provoquent un traitement automatique afin de silencieusement remettre tout en ordre et finalement le reste (de type Exception) qui va provoquer l'arrêt de l'appli avec rapport et stacktrace.
J'aurais vraiment aimer n'avoir a écrire que trois block catch ce jour la..

Bulbo

**verbose** · 19/12/2007, 15h14

Je suis contre, absolument contre. Cette proposition vient pervertir le langage pour une avancée tout à fait mineure. De plus, il est déjà possible de catcher plusieurs type d'exceptions à la fois si elles héritent d'un supertype commun.

**bulbo** · 19/12/2007, 15h20

Envoyé par verbose

Je suis contre, absolument contre. Cette proposition vient pervertir le langage pour une avancée tout à fait mineure. De plus, il est déjà possible de catcher plusieurs type d'exceptions à la fois si elles héritent d'un supertype commun.

Ca c'est dans le cas ou tu as la main sur tout les types d'exceptions qui peuvent être levées par ton programme.
Au jour d'aujourd'hui vu le nombre d'API sur le marché qui peut dire qu'il maitrise la conception de toutes les classes qu'il utilise ?

Dans l'absolu il y a une avancée, mineure mais il y en a une.

La 'perversion' du langage est vraiment mineure, limitée et facilement lisible (mais ce | brr

) contrairement a bien d'autres proposées ailleurs.

Bulbo

**le y@m's** · 19/12/2007, 17h43

Pour, mais comme déjà dit la syntaxe ne me paraît pas judicieuse.

**elitost** · 19/12/2007, 19h05

Encore une fois pour les possibilités de raccourcir le code , mais ici une syntaxe à explorer...

**mavina** · 19/12/2007, 19h54

Vu sous cet angle, oui mais pourquoi annoncer le parent dans le catch ?

pourquoi annoncer

Code :

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

catch(MonExcFille1,MonExcFille2 : MonExcMere)

et pas juste les exceptions filles? Je trouve que donner la classe mere ne sert pas à grand chose.

F.

**the-gtm** · 19/12/2007, 20h08

Envoyé par mavina

Vu sous cet angle, oui mais pourquoi annoncer le parent dans le catch ?

pourquoi annoncer

Code :

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

catch(MonExcFille1,MonExcFille2 : MonExcMere)

et pas juste les exceptions filles? Je trouve que donner la classe mere ne sert pas à grand chose.

F.

Il faut déclarer une classe parente, sinon dans ce code:

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
catch(MonExcFille1,MonExcFille2 : MonExcMere e) {
  processException(e);
}
 
public void processException(MonExcFille1 e) {
  // ...
}
 
public void processException(MonExcFille2 e) {
  // ...
}
 
public void processException(MonExcMere e) {
  // ...
}
 
public void processException(Exception e) {
  // ...
}

Le compilateur ne saura pas vers quel méthode résoudre processException().

**Ricky81** · 19/12/2007, 21h18

Envoyé par OButterlin

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

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.

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 :

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.

Et si tu ne veux justement pas catcher l'une des classes filles de PrinterException ?

Envoyé par the-gtm

Il faut déclarer une classe parente, sinon dans ce code:

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
catch(MonExcFille1,MonExcFille2 : MonExcMere e) {
  processException(e);
}
 
public void processException(MonExcFille1 e) {
  // ...
}
 
public void processException(MonExcFille2 e) {
  // ...
}
 
public void processException(MonExcMere e) {
  // ...
}
 
public void processException(Exception e) {
  // ...
}

Le compilateur ne saura pas vers quel méthode résoudre processException().

L'appel est résolu au Runtime en fonction de l'exception, donc je ne vois pas ce que le compilateur ferait dans l'histoire si ce n'est vérifier que tous les cas sont couverts.

**the-gtm** · 19/12/2007, 21h59

Je sais pas si c'est résolu au runtime ou à la compilation, mais en tout cas ça la méthode sélectionnée dépend du type déclaré de la variable. cf 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
public class ExceptionTest {
 
	public static void main(String[] args) {
		new ExceptionTest().test();
	}
 
	public void test() {
		MonExcMere e1 = new MonExcFille1();
		processException(e1);
	}
 
	public void processException(MonExcFille1 e) {
		System.out.println("MonExcFille1");
	}
 
	public void processException(MonExcFille2 e) {
		System.out.println("MonExcFille2");
	}
 
	public void processException(MonExcMere e) {
		System.out.println("MonExcMere");
	}
 
	class MonExcFille1 extends MonExcMere {}
	class MonExcFille2 extends MonExcMere {}
	class MonExcMere {}
}

C'est "ExceptionMere" qui est affiché, parce que la variable a été déclarée comme une ExceptionMere

**mavina** · 19/12/2007, 22h09

Envoyé par Ricky81

Et si tu ne veux justement pas catcher l'une des classes filles de PrinterException ?

Tu la catch à part avant non ?

Un truc du genre

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
try
{
(...)
}catch(PrinterAbortException pae)
{
//je ne fais rien
}catch(PrinterException pe)
{
//je fais
}

passe dans le premier catch lors d'une PrinterAbortException et dans le
second lors du reste non ? J'avoue n'avoir jamais eu ce cas ...

F.

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

**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{
        ...
    }
}

**woodwai** · 20/12/2007, 08h58

Pareil que beaucoup, pour la proposition mais contre la syntaxe (au minimum utiliser une virgule), la possibilité offerte de définir le type de l'exception passée au bloc catch permet aussi de ne pas devoir faire de 'instance of' pour déterminer le typage de l'exception dans le bloc catch si nécessaire.

Donc, +1 pour la syntaxe de Uther.