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

[bulbo]

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

[adiGuba]

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 :

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 :

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 :

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 :

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 :

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

[Uther]

Envoyé par mavina

Personnellement je suis plutot contre. Le fait est qu'on puisse catcher des exceptions avec un ancetre commun comme ceci :

Code :

est la même chose que de catcher dirrectement l'ancetre :

Code :

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 :

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.

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

[bulbo]

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

[bobuse]

Envoyé par adiGuba

Tu vas me dire on peut faire ceci :

Code :

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 :

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

Code :

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

[Jester]

Pour mais avec la syntaxe d'Uther.

[le y@m's]

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

[nicorama]

Envoyé par Uther

Pour le principe mais à condition d'utiliser une autre syntaxe.

Le "|" comme séparateur m'a fait sursauter. Ca me parrait une très mauvaise idée d'utiliser comme séparteur le même symbole qu'un opérateur binaire .
De plus, la classe de l'exception commune "e" n'est pas spécifié ce qui n'est pas naturel dans un catch(et en java tout court même).

Je verais plutôt une syntaxe du style:

Code :

+1

[elitost]

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

[mavina]

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

pourquoi annoncer

Code :

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]

Envoyé par mavina

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

pourquoi annoncer

Code :

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 :

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]

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 :

est la même chose que de catcher dirrectement l'ancetre :

Code :

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 :

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]

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 :

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]

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 :

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.

[Ricky81]

Je me suis mal exprimé en parlant de Runtime. Le catch multiple n'est que du sucre syntaxique, c'est comme si on écrivait un bloc catch par exception déclarée, donc le problème que tu évoques ne devrait arriver.

mavina là tu étouffes l'exception, il s'agirait de la propager tout simplement.

[the-gtm]

Envoyé par Ricky81

Je me suis mal exprimé en parlant de Runtime. Le catch multiple n'est que du sucre syntaxique, c'est comme si on écrivait un bloc catch par exception déclarée, donc le problème que tu évoques ne devrait arriver.

Je pense que je vois ce que tu veux dire : en gros c'est équivalent à plusieurs blocs catchs, chacun avec une exception en particulier.

Ca me semble quand même ambigu comme syntaxe. Si on reprend l'exemple

Code :

1
2
3
4
5
6
7
8
9
10
11
catch(MonExcFille1,MonExcFille2 e) {
  processException(e);
}
 
public void processException(MonExcFille1 e) {
	System.out.println("MonExcFille1");
}
 
public void processException(MonExcFille2 e) {
	System.out.println("MonExcFille2");
}

Si dans mon IDE je rentre dans la méthode du bloc catch(F3 avec eclipse), il m'ouvre laquelle?
En gros ça revient à mettre un peu de langage dynamique dans Java. C'est le "un peu de" qui me gène, soit le typage est dynamique soit il est statique, quand "ça dépend", c'est pas terrible

[bouye]

Pour, mais avec une syntaxe differente (des virgules semblent tout indiquees pour le travail).

[woodwai]

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.

[benwit]

Envoyé par Uther

Pour le principe mais à condition d'utiliser une autre syntaxe.

Le "|" comme séparateur m'a fait sursauter. Ca me parrait une très mauvaise idée d'utiliser comme séparteur le même symbole qu'un opérateur binaire .
De plus, la classe de l'exception commune "e" n'est pas spécifié ce qui n'est pas naturel dans un catch(et en java tout court même).

Je verais plutôt une syntaxe du style:

Code :

+2

Edité pour modif de syntaxe (cf ci dessous)