[Tsp-devel] Exception en JAVA dans Jtsp, suite

[Stephane Galles]

Pouf, pouf,

Je ne vais pas lancer un troll sur les exceptions en Java, il
y a surement des choses plus intéressantes à faire sur TSP,
mais neanmoins, je réagis à ça :

address@hidden wrote:

> 0) Il est également possible que je n'ai pas à capturer une
> exception mais juste devoir déclarer
> être capable de la jeter car j'appelle
> quelqu'un qui peut la jeter. C'est ce que j'appellerai
> laisser passer les bulles.
> Ce n'est peut-être pas de bon goût dans le cas
> d'exception d'une lib java non incluse dans le JDK
> (au cas où on voudrait en changer) mais ça me parrait
> "raisonnable" dans bien des cas.
Effectivement, je reprend ton terme, ce n'est pas de bon gout,
car tu va obtenir un pollution des packages. Alors effectivement
je comprend qu'un peu de mauvais gout de temps en temps cela
ne fait pas de mal si cela evite du codage juste pour la gloire.

Mais cela va devenir beaucoup plus génant pour un autre raison qui
n'a rien à voir en tant que tel avec les pollutions de package :

Ton API va devenir inutilisable parceque polluée par des exceptions
que le pauvre utilisateur de l'API ne saura pas comment traiter
(une exception RPC c'est quoi ? C'est quoi du RPC ? c'est grave ?
je peux faire quoi avec une exception RPC ? C'est une erreur fatal ?
pas fatal ? dieu existe il ? que fait la police ? Quand est ce qu'on 
mange ?)

Alors qu'en fait le plus souvent c'est une erreur fatale, et aucun 
traitement
applicatif particulier ne peut être fait. Tu a juste lancé une exception 
pour
aider l'utilisateur à quitter le flot d'execution proprement.

(Pour ceux que le language JAVA n'interesse pas, vous pouvez
arreter de lire ici, je vais être soporifique. En fait non, tout bien
réfléchi je vais être soporifique pour tout le monde ; pas grave,
je continue...)

Neanmoins, il faut savoir que depuis le JDK 1.4 le language prend
en compte ce probléme EN NATIF. Cela s'appelle
les 'Exception Chaining', et il serait bien dommage de ne pas
l'utiliser.
http://www.scd.ucar.edu/nets/intro/staff/siemsen/java/exceptions/Exception-Chaining.html

La force de ce systéme est que le chaining ce fait en une seule ligne :

}catch(ExceptionPasDeMonPackage e){
   throw new ExceptionDeMonPackage(e);
}

De plus, quand au plus au niveau tu récupéres ton exception, tu es
capable de voir TOUT l'historique du chaining et comprendre
quelles sont les couches qui ont été traversées par l'exception.

En résumé, le plus souvent quand tu as un package donnée tu n'a besoin 
de lancer
qu'une exceptions propre au package, sauf si tu a besoin de distinguer
des erreurs pour en faire un traitement applicatif.

Je dis bien traitement APPLICATIF sinon une seule exception suffit.

Si c'est juste pour comprendre ce qui  s'est passé post mortem,
un bon println(e) dans un log te dira ce qui c'est passé via 
l'historique du chaining.

Dans notre cas, je suis persuadé que dans le package tsp.core.consumer
tu n'as juste besoin que d'une seule exception par exemple
TspConsumerException, et tu chainnes toutes les exception dans celle lá

Quand dans la couche du dessous tu te ramasse une exception, par exemple
Rpc, il ne faut surtout pas la remonter plus haut ! En quoi cela intéresse
un utilisateur de notre API ? Il sait ce que c'est seulement du Rpc ?
Il sait comment le traiter ? il va aller chercher la spec Rpc pour
savoir ce qu'il s'est passé et comprendre les 2000 codes
d'erreur du Rpc qui seront dans l'exception et faire des traitements
différents en fonction de cela ?

S'il ne peux rien en faire autant tout Wrapper dans TspConsumerException,
car dans ce cas, l'exception est juste utilisée pour quitter le flot 
d'execution.

Par contre, si tu veux donner un information utilisable applicativement 
pour l'utilisateur, tu
peux effectivement faire un exception particulière pour lui préciser par 
exemple
que le serveur n'est pas lancé. Dans ce cas, l'exception Rpc qui indique 
que le
serveur n'est pas lancé et chainné dans une TspProviderNotLaunchedException
et tout le reste en vrac dans TspConsumerException. Comme cela une IHM
pourrait dire à l'utilisateur de lancer son serveur. Dans le cas d'une 
TspConsumer
exception c'est simplement pour dire : probléme fatal, consulter les traces,
ou se trouvera le dump de TspConsumerException avec au milieu de la 
stackTrace
tous les détails de l'exception RPC

Mais j'irai plus loin : imaginons que dans la couche du dessous tu te 
ramasse
un exception java IOException. Tu vas la remonter ? J'ai cru comprendre que
tu voulais parceque 'c'est une exception Java'. Ce n'est pas une raison pour
polluer la signature de ta fonction si cela ne permet pas de faire faire un
traitement applicatif lié à cette information. Si le but c'est de 
quitter le flot
d'execution, que ce soit une IOException ou bien une WhateverException,
si l'utilisateur ne peut rien en faire applicativement, même une 
IOException tu la chainnes
dans une TspConsumerException. Avec le chaining tu ne perds pas 
d'informations
au final pour une analyse post mortem de l'arret de l'application.

Voila, je me suis un peu emballé là, mais plus j'utilise les exception 
en JAVA,
plus je me rend compte qu'on peut faire des API extrémement propres et 
faciles
à documenter, donc je trouvais cela rallant de passer à coté.

Bon WeekEnd

Steph.