Wiki de Programmation GWT 2 Wiki de Programmation GWT 2

page 184-185 Exceptions non vérifiées

Bonjour Sami,

Dans le paragraphe "Exceptions non vérifiées", il est dit que dériver de RuntimeException à peu d'intérêt avec GWT.

Pour ma part je trouve qu'il y a un intérêt, à la condition de savoir l'utiliser.

Voici la manière dont je l'utilise:

J'encapsule les appels Rpc par une méthode grâce à l'AOP. Je fais un try catch de toutes les méthodes d'appels Rpc sur Throwable.

Lorsqu'une exception se produit, quelque soit son type, je la transforme en une RuntimeException que j'ai étendu et qui est connu par mon module GWT. Cette exception est dans la signature de mon appel Rpc. Ainsi je peux la récupérer proprement côté client afin d'afficher des messages propres à l'utilisateur final.

On peut donc étendre une RuntimeException, la déclarer dans les signatures des appels Rpc afin de retirer tous les blocs try catch des appels Rpc. Cela allège le code et centralise la gestion des erreurs.

On peut également ajouter des attributs à notre RuntimeException afin d'ajouter des informations à afficher à l'utilisateur final.

Ceci est très utile pour gérer proprement les Validateurs Hibernates.

Cdt, Philippe Voncken

0 Attachments 0 Attachments
224 Views

Average (0 Votes)

  • Comments
Sami Admin
Bonjour Philippe,

Sur ce point précis j'avoue que je ne partage pas cette démarche. Pour plusieurs raisons :
1) une exception de runtime est une exception *unchecked*. Une exception "normale " est du type checked. En utilisant de l'AOP pour modifier des signatures de services tu masques le contrat d'interface à ton client uniquement pour contourner les limitations de GWT. Si on avait poussé la cohérence du raisonnement jusqu'au bout, autant utiliser des exceptions normales, qu'est-ce que les runtime t'apportent excepté le fait de ne pas exiger du client un try catch{} ?

2) C'est typiquement le genre de scénario où je trouve l'emploi de l'AOP dangereux, un client qui lit ton contrat d'interface ne sait pas qu'à l'exécution tu gères des exceptions métier "dans son dos".

3) Que se passe t-il si un développeur met directement dans son contrat d'interface une exception du même type (même nom mais pas même package) que celle que tu es censé rajouter, mais dont la sémantique est différente ? Il va y avoir un try catch assez bizarre à gérer...

Sami

Posted on 3/5/10 9:12 PM.

Top Top