Discussion :

[tnarol]

Bonjour,

Dans mon post précédent http://www.developpez.net/forums/d10...s/#post5801720 adiGuba me disait que c'est une mauvaise pratique d'utiliser la facilité de déclarer une méthode avec "throws Exception" pour lui éviter d'avoir à redéclarer la liste complète des exceptions qu'elle rencontre et surtout éviter d'obliger ses utilisateurs à gérer individuellement ces exceptions.

Est-ce que vous pourriez expliquer précisément en quoi ça pose problème ? Y a t-il une différence notable avec un "throws UserCustomExcepton" ?

Merci

[Dark-Water]

Bonjour,

Avec throws Exception tu ne peut pas adapter ton catch en fonction de l'exception (fermer une connection , un fichier ...) de plus pour le développeur qui utilise ta méthode il ignore quelle sont les types d'exceptions remontées. Cela compromet sa compréhention de ta méthode. De plus Exception te récupère toutes les exceptions y compris celles que tu n'a pas obligation à catcher (ex nullPointerException)

Voila donc il faut être prudent lorsque l'on utilise throws Exception

[tnarol]

Bonjour,

Avec throws Exception tu ne peut pas adapter ton catch en fonction de l'exception (fermer une connection , un fichier ...) de plus pour le développeur qui utilise ta méthode il ignore quelle sont les types d'exceptions remontées. Cela compromet sa compréhention de ta méthode. De plus Exception te récupère toutes les exceptions y compris celles que tu n'a pas obligation à catcher (ex nullPointerException)

Voila donc il faut être prudent lorsque l'on utilise throws Exception

Merci ! Je suis d'accord avec ces arguments, effectivement Exception peut cacher certaines exceptions non prévues et donc influencer le code utilisateur dans le sens de catcher des choses qu'il ne devrait pas. Cependant le fait de chainer les exceptions "causes" dans une exception utilisateur (différente de Exception) ne permet pas beaucoup plus à l'utilisateur extérieur de la classe d'avoir une idée précise de ce qui est remonté.

Dans mon cas précis je suis coincé entre la solution super lourde de propager un grand nombre de types d'exceptions à travers plusieurs couches applicatives ou la solution légère de restreindre ce grand nombre à un ou deux types mais en perdant au passage une grande partie de l'intérêt qu'il y a à avoir précisé ces exceptions au départ.

Relativement nouveau venu à Java je suis relativement d'accord avec les critiques faites aux checked exceptions que j'ai pu trouver :
http://radio-weblogs.com/0122027/sto...eAMistake.html

http://www.artima.com/intv/handcuffsP.html

[adiGuba]

Salut,

Le fait de remonter Exception n'arrange en rien le "problème" des checked-exceptions ! Au contraire un des problèmes des checked-exceptions vient justement du fait que beaucoup "simplifie" cela en "throws Exception"

Si tu ne veux pas de checked-exceptions, tu n'as qu'à utiliser des unchecked-exceptions...

a++

[tchize_]

Il y a deux chose possible.

Soit parmis la miriade des exceptions qui peuvent remonter, l'appelant à haut niveau a besoin de savoir laquelle précisément à étél lancée (IOException, DateFormatException, etc). Dans ce cas, vous déclarez tout ce qui doit remonter, individuellement.

C'est cependant en général une mauvaise pratique. En réalité, si vous avez plusieurs couche, chaque couche "cache" les détails de la couche en dessous, c'est pour ça qu'on les crée. ainsi, si une couche est chargée du stockage de données, celui qui l'appelle s'en fous que le problème vienne d'un IOException, d'un disque full, d'un filenotfound, etc. Tout ce qui lui importe c'est de savoir qu'il y a, par exemple, eu un PersistenceException, qui implique qu'on a pas pu sauver, et il prend les mesure nécessaire.

Ainsi, quand vous utiliser, par exemple, le parseur XML de java, vous catchez des exception SAX, qui vous informent que le document a un problème. vous n'avez pas besoin, au niveau du code, de savoir précisément que derrière ça s'est déclenché un NumberFormatException, un SocketException etc. Tout ces détails qui ne servent qu'aux dev pour son debugging sont dans la "cause" qu'on loggue dans un coin au cas ou, et c'est tout.


Quand à Exception:

Forcer l'utilisateur à devoir écrire

Code :

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

1
2
3
4
5
6
try{
 votreApi.uneMethode();
 uneAutreApi.uneAutreMethode();    
} catch (Exception e){
  //....
}

C'est à la fois le forcer à traiter des cas qu'il ne veux pas traiter, et lui rendre la vie impossible pour séparer les différente cause d'erreur (qui a foiré, une methode ou un autre ?)

[professeur shadoko]

Relativement nouveau venu à Java je suis relativement d'accord avec les critiques faites aux checked exceptions que j'ai pu trouver :
http://radio-weblogs.com/0122027/sto...eAMistake.html

http://www.artima.com/intv/handcuffsP.html

le problème c'est qu'il est difficile d'expliquer en quelques lignes pourquoi je ne suis pas d'accord:avec tout le respect que je dois à Anders Heijsberg je trouve qu'il met dans le même sac différentes catégories de problèmes.
J'ai un peu l'impression qu'il dit : comme les programmeurs ont tendance à cochonner leur code ne les embétons pas ("vous en réviez, Microsoft l'a fait!")
J'ai du mal à imaginer que quand un service fait appel à une série de couches on puisse se retrouver avec une megach***+N exceptions. Tu demandes un service il te répond qu'il ne peut pas, dans les couches sous-jacentes une série de causes peuvent agir en cascade mais il faut avoir un sacré problème de conception pour se retrouver avec une pluie d'exceptions possibles.
Maintenant il est vrai qu'avec des services abstraits (premier article) c'est un peu plus compliqué...

[tnarol]

Merci pour vos remarques qui me permettent d'y voir plus clair.