Discussion :

[Ithildine]

Pourquoi vouloir à tout prix énumérer chaque type d'exception trapée pour au final faire le même traitement ?
Qu'est-ce qui vous déplait tant dans le fait de ne garder qu'un seul et unique bloc qui trape le type Exception ou éventuellement un type commun plus précis ? Qu'est-ce qui vous manque dans cette solution si simple ?
Ok, on risque de prendre plus de monde avec une classe mère commune, mais est-ce si grave que cela ?

Plusieurs d'entre vous l'ont dit : peu importe le type trapé, le traitement au final reste le même et l'exception sera ensuite remontée à l'appelant. Vraiment, je ne vois pas ce que ces syntaxes apportent de vital qui n'existerait pas déja dans le langage, à par une complexité cachée additionnelle et les risques d'incompréhension habituel de ce genre de gadget.

[austin P.]

Encore une fois je ne comprends pas ou est le probleme : dupliquer le code, c'est pas obligatoire, le code dupliqué pouvait facilement se mettre dans une fonction,

ce qui vas ajouter une liste sans fin (Déjà qu'on se plain avec les kilomètres de getters/setters....) de méthode private dans ton code source et, que tu le veuille ou non, rendre la lecture plus complexe.
En plus j'ai du mal à voir comment tu vas les nommer ces méthodes?
methodeName_exception ? et si tu gère plusieurs fois la même exception dans ta méthode tu fais
methodeName_exception1
methodeName_exception2
methodeName_exception3 ... ?

pas sur que ce soit très lisible tout ça.

[tchize_]

Ok, on risque de prendre plus de monde avec une classe mère commune, mais est-ce si grave que cela ?

Oui c'est grave, quand ton type commun est "Exception", tu va chopper toutes les runtimeexception qui n'ont probablement rien à voir avec le traitement prévu. Les exceptions imprévues doivent remonter jusqu'à un niveau ou on les gère, pas subir un traitement qui ne leur est pas approprié et disparaitre.

[austin P.]

Pourquoi vouloir à tout prix énumérer chaque type d'exception trapée pour au final faire le même traitement ?

pour ne pas dupliquer ce même traitement

Qu'est-ce qui vous déplait tant dans le fait de ne garder qu'un seul et unique bloc qui trape le type Exception ou éventuellement un type commun plus précis ?

hum des outils comme pmd, checkstyle et consort déconseillent tous fortement l'utilisation du catch Exception : je pense qu'il y a une bonne raison à cela.

Ok, on risque de prendre plus de monde avec une classe mère commune, mais est-ce si grave que cela ?

oui

la gestion des exceptions reste une science exacte : peu de place pour de "l'a peu près". Le diagnostic n'en sera que plus simple.

Plusieurs d'entre vous l'ont dit : peu importe le type trapé, le traitement au final reste le même et l'exception sera ensuite remontée à l'appelant.

ce n'est pas mon cas
chaque couche/layer encapsule l'exception et celle ci gagne (en traversant chaque couche) en granularité. Au final ma GUI se fiche pas mal de savoir que la BDD est tombé, ou que le réseau dans la DMZ est indisponible. Elle à juste à savoir que le service est indisponible.

Vraiment, je ne vois pas ce que ces syntaxes apportent de vital qui n'existerait pas déjà dans le langage, à par une complexité cachée additionnelle et les risques d'incompréhension habituel de ce genre de gadget.

ce n'est pas vital : c'est juste du confort

pourquoi avoir un while alors que je peut le simuler avec un for ?
du confort

[deltree]

J'avais déjà exprimé mes réticences, mais ça peut être un plus pour la lisibilité, donc vous m'avez convaincu.
Mais il reste le problème du type catché, pour moi soit on indique le type parent à utiliser, soit c'est "Throwable" tout le temps, qui est suffisant dans la plupart des cas.
Ce qui dans ce cas donne quelque chose comme:

Code :

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

1
2
3
4
5
6
7
8
9
10
 
	try {
		Object test = Class.forName("aaa").newInstance();
	} catch (InstantiationException, IllegalAccessException,ClassNotFoundException  e) {
		e.printStackTrace();
		//si vraiment on veut typer
		doSomething((Exception) e);
	}
 
}

il faut vraiment éviter un typage automatique de "e" en "Exception" (la superclasse commune dans mon exemple).

[mavina]

ce qui vas ajouter une liste sans fin (Déjà qu'on se plain avec les kilomètres de getters/setters....) de méthode private dans ton code source et, que tu le veuille ou non, rendre la lecture plus complexe.
En plus j'ai du mal à voir comment tu vas les nommer ces méthodes?
methodeName_exception ? et si tu gère plusieurs fois la même exception dans ta méthode tu fais
methodeName_exception1
methodeName_exception2
methodeName_exception3 ... ?

pas sur que ce soit très lisible tout ça.

Euh, si toutes tes exceptions sont catchées en même temps, tu n'as qu'une fonction à faire, que tu places dans chaque catch...
Une fonction private donc, ce n'est pas la mort à trouver un nom pour une fonction qui traite un cas d'exceptions commun...

F.

[austin P.]

Euh, si toutes tes exceptions sont catchées en même temps, tu n'as qu'une fonction à faire, que tu places dans chaque catch...
Une fonction private donc, ce n'est pas la mort à trouver un nom pour une fonction qui traite un cas d'exceptions commun...
F.

cela ne vaut que si et seulement si tu n'a qu'un cas de gestion d'exception dans une classe et c'est un cas peu probable voir improbable. Prenons une classe contenant 30 methodes, j'ai peine à croire qu'une seule gestion d'exception suffise même si cette classe est fortement cohésive.

Ici on ne cherche pas à regrouper tous les cas d'exception d'une classe vers une seule méthode mais bien de pouvoir faire un regroupement de gestion d'exception suivant leur affinité fonctionnelle/technique.

tu te retrouvera donc bien avec un ensemble de méthodes private pour la gestion des exception.


Pour ajouter à mon propos, je pense aussi que d'utiliser des méthodes private pose aussi un problème de porté. En effet si je modifie une de ces méthodes private, je peux difficilement dire (et vérifier) si cette modification est bonne pour tous les bloc catch de ma classe qui la pointe.

Ici on recherche moins à éviter le copier-coller dans toute une classe que de simplifier et de rendre plus lisible/moins envahissante la gestion des exceptions.

[_skip]

Et encore, ça suppose que la méthode de gestion d'exception n'ait pas besoin de variables ou de références appartenant au contexte de la méthode dans laquelle se trouve le code qui a déclenché l'erreur.

C'est un excellent progrès à mon sens car je trouve que c'est justement sur ce genre de chose que java a du retard par rapport à son concurrent c#.

[Ricky81]

C'est un excellent progrès à mon sens car je trouve que c'est justement sur ce genre de chose que java a du retard par rapport à son concurrent c#.

Bonjour,

Je suis assez surpris par ta remarque (mais je ne connais pas suffisamment C#). Pourrais tu illustrer ton propos ?

[_skip]

Bonjour,
Je suis assez surpris par ta remarque (mais je ne connais pas suffisamment C#). Pourrais tu illustrer ton propos ?

Le sujet a été débattu sur le forum best of des débats. Le C# offre la syntaxe "throw;" qui permet de propager une exception depuis un bloc catch sans perte de la stacktrace originale, et donc sans le besoin d'encapsulation.
Pour les cas ou je me fiche de savoir quel est le type de l'exception déclenché mais que je veux juste pouvoir déclencher un rollback ou effectuer un nettoyage (et c'est le cas 9 fois sur 10 dans ma BLL), c'est un gain en code et en lisibilité considérable.

En gros on peut faire un code du style :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
try
{
     //code déclenchant une exception
}
catch(Exception ex)
{
      if( !(ex is MonException1 || ex is MonException2 || ex is MonException3 )  )
             throw;
 
      //gérer un cas général d'exception ici, afficher un message etc...
}

Ou encore de ce genre :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
try
{
     //code déclenchant une exception
}
catch(Exception ex)
{
      if(connection.IsOpen() )
      {
              Transaction.Rollback();
              connection.close();
      }
 
      throw; //propager
}

Cette nouvelle syntaxe en java permet justement de répondre à tous ces cas ou on se fiche du type exact de l'exception, mais qu'on veut simplement être en mesure de réagir à une erreur avant de propager l'exception plus haut.
On fait cela très souvent dans les applications n-tiers, on veut que la couche profonde signale que quelque chose de mauvais est arrivé mais la décision d'arrêter l'application ou de continuer l'exécution après un gentil message d'erreur est prise par la couche de surface.

[djsnipe]

Je ne vois pas dans ce code quelque chose de plus qu'en Java aujourd'hui :
- On catch une Exception de haut niveau et après on teste le type réel. En Java, pareil catch(Exception e) puis des instanceof
- Propagation d'exception, sans rien perdre non plus, mais ok en java il faut rajouter le nom de la variable contenant l'exception, donc "throw ex" dans ton exemple au lieu de "throw".

Où est l'avantage du C# ?

[_skip]

Je ne vois pas dans ce code quelque chose de plus qu'en Java aujourd'hui :
- On catch une Exception de haut niveau et après on teste le type réel. En Java, pareil catch(Exception e) puis des instanceof

Tu peux pas faire ce genre de chose, si tu essaies de relancer Exception, tu vas être obligé de mettre des catch( Exception ) partout sur toute les méthodes appelantes car Exception est une checked exception.

- Propagation d'exception, sans rien perdre non plus, mais ok en java il faut rajouter le nom de la variable contenant l'exception, donc "throw ex" dans ton exemple au lieu de "throw".

Si tu fais throw ex, que ce soit en java ou en C#, tu perds une partie précieuse des informations de la pile, en fait ça donnera l'impression que c'est ton code de gestion d'erreur qui a déclenché l'exception, alors qu'en vérité c'est quelque chose dans le code du bloc try plus haut.

[djsnipe]

Tes 2 explications sont sur le fait de relancer l'exception.
Le gros catch en C# que tu décrit reste pour moi identique en Java.
Maintenant, les "précieuses informations de la pile", et le simple "throw" du C#, je ne vois toujours pas. Si dans ton exemple, le throw propage l'exception, pourquoi ne faudrait-il pas la catcher au niveau supérieur ? Pour la pile, si je choisi de faire un catch, c'est bien justement que je souhaite traiter l'erreur à mon niveau. Pour faire remonter des erreurs de couche en couche, je ne propage jamais l'exception initiale, ca ajoute du couplage inutile entre une couche de présentation et de persistance. Donc systématiquement, j'encapsule et je ne perd pas d'info. Et quand je ne peux pas traiter une exception qui par nature serait irrécupérable, je la propage justement en Runtime.

Au final, d'après tes explications, C# et Java sont sensables, ils permettent de faire la même chose, à qq pouillièmes de syntaxe.

[Edit] Je ne relancerai pas le topic sur cette apartée, trop éloignée du sujet initial.

[_skip]

Si dans ton exemple, le throw propage l'exception, pourquoi ne faudrait-il pas la catcher au niveau supérieur ?

Le but d'une exception c'est pas forcément qu'on la catche, seul 1/5 à peine de mes blocs try ont une clause catch(), par contre beaucoup de finally. Les seuls moments ou une clause catch m'intéresse ne sont pratiquement que ceux pour lesquelles j'ai un rollback à effectuer. Je ne vais pas m'amuser à catcher des exceptions partout si c'est pour ne rien faire de plus qu'un handler global.

Pour faire remonter des erreurs de couche en couche, je ne propage jamais l'exception initiale, ca ajoute du couplage inutile entre une couche de présentation et de persistance. Donc systématiquement, j'encapsule et je ne perd pas d'info.

Je suis un peu différent, je déteste l'idée de décorer des exceptions juste pour avoir de l'abstraction sur les couches inférieures sans ajouter aucune information ou aucune fonctionnalité. Je le fais seulement si les exceptions remontées n'ont pas de sens ou sont imprécises aux yeux de la couche appelante.

Et quand je ne peux pas traiter une exception qui par nature serait irrécupérable, je la propage justement en Runtime.

Donc ça veut dire que c'est ta couche inférieure et non celle de surface qui décide de la réaction de l'application à une situation d'erreur, j'ai une philosophie différente. Si une exception est levée parce qu'une connexion à un service échoue, dans mes programmes c'est la couche UI qui décide si elle veut terminer l'appli, ou proposer de réessayer, dans tous les cas ce qui m'împorte c'est d'avoir bien nettoyer derrière moi, fermer les connexions et annuler les transactions.

Ca ferait un excellent débat ça.

[xavlours]

Le sujet a été débattu sur le forum best of des débats. Le C# offre la syntaxe "throw;" qui permet de propager une exception depuis un bloc catch sans perte de la stacktrace originale, et donc sans le besoin d'encapsulation.

C'est vrai que c'est actuellement impossible en java, et l'exemple de code est pertinent : en java la syntaxe ne permet pas de catcher "tout sauf les Exception de type Exception1, Exception2, etc". On est obligés de passer par l'encapsulation de l'exception "cause" dans une nouvelle exception "effet":

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
try {
 
} catch(Exception cause) {
  if(cause instanceof Exception1 || cause instanceof Exception2 || ...) {
    Exception effet = new TrucException(cause);
    throw effet;
    // la stack trace de 'effet' est suivie de la mention "caused by"
    // puis de la stack trace de 'cause'
  }
 
  // on gère les autres types d'exceptions
}

Par contre, la fonctionnalité sur laquelle tu t'appuies pour éviter l'encapsulation est le rethrow d'exceptions, en débat dans cette discussion plutôt que le catch multiple, non ?

[_skip]

Il me semble que c'est bien le rethrow qui fait l'objet de l'autre proposition. Pas encore regardé d'assez près pour être sûr. Mais vraiment ça y ressemble.

Cette proposition et celle que tu as pointé sont deux solutions acceptables je trouve. Le problème de fond est toujours un peu le même, il y a aucune syntaxe qui permet de laisser l'exception telle quelle tout en ayant la possibilité de réagir à l'erreur ou tout au moins d'éviter la duplication du code de gestion.
C'est utile pour tout ce qui ne peut pas se faire avec une clause finally (un rollback dans le cas d'une BDD par ex.).

Je trouve que ces nouveautés iraient dans le bon sens, de toutes façons il y a forcément des cas dans lesquels ces choses sont pertinentes et d'autres ou elles ne le sont pas vraiment.

[deltree]

Que ce soit dans l'ancienne ou dans la nouvelle syntaxe il ne FAUT PAS catcher directement Exception ou pire: Throwable, mais directement les types que l'on doit traiter.
1. utiliser finally quand on doit faire un traitement avant une sortie d'exception (le rollback le plus souvent) (edit: oops pas le rollback mais la fermeture de connection)

2. faire un catch pour faire ensuite un rethrow sans encapsulation ça n'est pas efficace et inutile: autant faire simple (lancer et catcher une exception est couteux, le instanceOf est également couteux)

3. même si le risque est faible, il y a toujours un risque qu'un traitement d'exception plante et on perd alors l'exception originelle: le traitement est faux.

Finalement, le seul cas ou il faut catcher toutes les exception est le plus haut niveau d'un serveur d'application, d'un service, bref quand on traite réellement les exceptions sans les relancer.

Il doit y avoir de bien meilleure sources que moi sur le bon usage de l'exception, mais à ma connaissance aucune ne conseille de catcher l'exception. Il faut rappeler ce qui nous semble les "règles de l'art", plutôt que proposer des contournements.

en conclusion, cette nouvelle syntaxe nous inciterait à utiliser correctement les exceptions en simplifiant la syntaxe du catch.

[_skip]

-Tu peux tout à fait catcher exception du moment que tu fais une propagation en bonne et due forme et sans perte de l'information, java impose d'éviter ce genre de chose à cause des checked exceptions, mais dans d'autres langages c'est possible et tout à fait propre et sérieux.

-finally ça se déclenche aussi si tout s'est bien passé, c'est l'endroit idéal pour libérer des ressources mais pas pour effectuer un rollback.

-Si l'exception est exceptionnelle on s'en fout de perdre même 100ms en rethrow. Typiquement un cas ou on doit faire un rollback ça devrait pas être tous les 2 appels.

[®om]

Si l'exception est exceptionnelle

Dans ce cas, sa gravité est gravitationnelle.

[adiGuba]

Le sujet a été débattu sur le forum best of des débats. Le C# offre la syntaxe "throw;" qui permet de propager une exception depuis un bloc catch sans perte de la stacktrace originale, et donc sans le besoin d'encapsulation.
Pour les cas ou je me fiche de savoir quel est le type de l'exception déclenché mais que je veux juste pouvoir déclencher un rollback ou effectuer un nettoyage (et c'est le cas 9 fois sur 10 dans ma BLL), c'est un gain en code et en lisibilité considérable.

En gros on peut faire un code du style :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
try
{
     //code déclenchant une exception
}
catch(Exception ex)
{
      if( !(ex is MonException1 || ex is MonException2 || ex is MonException3 )  )
             throw;
 
      //gérer un cas général d'exception ici, afficher un message etc...
}

[/quote]
Désolé mais ceci est tout à fait possible en Java également, à une nuance syntaxique près puisqu'il faut faire suivre le throw par la référence de l'exception :

Code :

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

throw ex;

Tu peux pas faire ce genre de chose, si tu essaies de relancer Exception, tu vas être obligé de mettre des catch( Exception ) partout sur toute les méthodes appelantes car Exception est une checked exception.

La différence est bien là ! En C# il n'y a pas de checked exception, contrairement à Java...

C'est un choix philosophique de ces deux langages, et chacun ayant ses avantages et ses défauts. Java force les développeurs à gérer les checked-exceptions, tandis qu'en C# on peut ignorer toutes les exception.

Mais perso cela importe peu car la qualité de la gestion des exception dépend du développeur et non pas du langage...

Si tu fais throw ex, que ce soit en java ou en C#, tu perds une partie précieuse des informations de la pile, en fait ça donnera l'impression que c'est ton code de gestion d'erreur qui a déclenché l'exception, alors qu'en vérité c'est quelque chose dans le code du bloc try plus haut.

Faux, lorsque tu fais un throw l'exception est remonté tel quel et son stacktrace n'est pas modifié. Le stacktrace d'une exception est déterminé lors de sa création...

Ce n'est que lorsqu'on crée une nouvelle exception que l'on perd le stacktrace initiale, mais on utilise alors la forme suivante qui permet de passer l'exception cause :

Code :

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

throw new MonException("message", ex);

-Tu peux tout à fait catcher exception du moment que tu fais une propagation en bonne et due forme et sans perte de l'information, java impose d'éviter ce genre de chose à cause des checked exceptions, mais dans d'autres langages c'est possible et tout à fait propre et sérieux.

La seule chose que Java impose, c'est de déclarer les checked-exception que l'on remonte...


a++