Discussion :

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

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

[Uther]

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.

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

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]

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

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

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 :

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

1
2
3
...
catch (InstantiationException, IllegalAccessException : Exception e){
...

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

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]

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]

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.

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 ?

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]

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]

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.

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

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 :

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

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]

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 :

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

1
2
3
...
catch (Exception e : InstantiationException, IllegalAccessException){
...

+2

Edité pour modif de syntaxe (cf ci dessous)