Discussion :

[Mens Pervincet]

J'ai regardé le code source du framework web "play framework", et j'y ai découvert une utilisation détournée des exceptions, que je trouve plutot élégante mais peu conventionnelle.

Les requêtes http sont traitées dans la méthode invoke de la classe ActionInvoker.
De nombreuses Classes (RenderJSON, RenderStatic, RenderXml..) héritent d'une même classe exception "Result" et surchargent une méthode "apply".

Le traitement de la requête se fait alors de cette façon:
l'ActionInvoker effectue des traitements, et appelle des méthodes qui aboutissent à la levée d'une exception fille de la classe "Result" ( par exemple RenderJson) .
L'exception est alors catchée et la méthode "apply" de l'exception est appellée (dans notre exemple, la méthode apply de la classe RenderJson).

C'est la première fois que je vois ce genre d'utilisation des Exceptions, trouvez vous ça élégant, est-ce déconseillé, pourquoi ?

[tchize_]

je trouve, vu ta description, que c'est une cochonnerie. Non seulement, une exception consomme plus de performances qu'un simple return de la valeur de retour (on aurait pu faire un simple return de l'objet à renvoyer), mais de surcroit, c'est un anti pattern. Ca fait des années qu'on enseigne aux nouveaux programmeur qu'il ne faut pas utiliser une exception comme un valeur de retour. Ce n'est pas destiné à ca. Une exception = un cas d'erreur.

De plus, en cas de plusieurs niveaux d'appel, alors qu'un exception peut "disparaître" à un niveau intermédaire, suite à une autre exception déclenchée dans un bloc finally, Une valeur de retour peut toujours s'attraper et être retransmise plus en avant.

[Mens Pervincet]

En fait je pense que j'ai pas forcément bien décrit la situation.
Les méthodes qui lèvent les exceptions sont statiques, dans une classe Controller.

Lorsque le développeur veut créer un contrôleur dans le framework play, il étend cette classe. Et il peut (mais ce n'est pas forcément le cas) invoquer une méthode mise à sa disposition telle que renderXXX.
Le traitement propre à render XXX ne concerne en rien le développeur, mais uniquement le framework, en procédant par valeur de retour, cela contraindrait le développeur à retourner une valeur dans l'action du contrôleur, même s'il n'en n'a pas besoin, ce qui est pour moi moins élégant que la méthode ansi employée.
(c'est ce qui est fait dans struts d'ailleurs ...)

Niveau performance, je comprends, mais c'est clairement pas le "bottleneck" dans une appli web. (généralement c est le parsing du langage de template servant à générer le HTML)

Concernant la "propagation", je suis d'accord, mais je ne trouve pas forcément incohérent que le Result "disparaisse" si une véritable Exception est levée dans un bloc finally, sachant que la réponse ne pourrait pas s'opérer. ( C'est embetant surtout pour investiguer l'erreur )

Peut on permettre au développeur de d'affranchir d'une valeur de retour "artificielle" sans passer par un mécanisme d'exception ?

Pourquoi est-ce un anti pattern, y a -t-il d'autres arguments?

[adiGuba]

Salut,

Et il peut (mais ce n'est pas forcément le cas) invoquer une méthode mise à sa disposition telle que renderXXX.
Le traitement propre à render XXX ne concerne en rien le développeur, mais uniquement le framework, en procédant par valeur de retour, cela contraindrait le développeur à retourner une valeur dans l'action du contrôleur, même s'il n'en n'a pas besoin, ce qui est pour moi moins élégant que la méthode ansi employée.

Je ne vois pas en quoi une exception serait plus pratique pour retourner un résultat

(c'est ce qui est fait dans struts d'ailleurs ...)

Heu...
Tu as un exemple concrêt ? Jamais rien vu de tel dans Struts 1...

Niveau performance, je comprends, mais c'est clairement pas le "bottleneck" dans une appli web.

La création d'une exception implique la création du stacktrace... assez coûteux mais utile pour la résolution de l'erreur.

Peut on permettre au développeur de d'affranchir d'une valeur de retour "artificielle" sans passer par un mécanisme d'exception ?

Que veux-tu dire exactement par "valeur de retour artificielle" ???


a++

[Mens Pervincet]

Salut,

Heu...
Tu as un exemple concrêt ? Jamais rien vu de tel dans Struts 1...

Les actions de struts 1 retournent un ActionForward qui sera référencé dans le struts-config.xml pour que le framework aiguille ensuite sur la vue correspondante.

C'est un choix comme un autre, mais dans le cas par exemple de requêtes Ajax (pas gérées par struts 1) on est obligé d'écrire le flux soi même et de retourner NULL, ce qui n'est pas forcément super élégant.
Tu as des exemples dans la FAQ:
http://javaweb.developpez.com/faq/st...=trucs_astuces

Je trouve la manière de faire de play plus "épurée" puisque: pas d'Action Forward à remplir et à retourner: c'est la méthode renderXXX qu'on aura décidé d'invoquer ou non qui va définir la suite du processus, géré par le framework. C'est d'ailleurs en me questionnant sur cette façon de faire "magique" que j'ai vu qu'ils utilisaient cette astuce sur les exceptions dans le code source du framework.

Après ça peut se discuter ^^ c'est pour ça que je me posais la question du bien-fondé.

Sinon l'un des problèmes que j'y vois mis à part ceux évoqués par tchize c'est que le développeur n'est pas forcément au courant que le code placé après son renderXXX() sera court-circuité ....

[adiGuba]

Les actions de struts 1 retournent un ActionForward qui sera référencé dans le struts-config.xml pour que le framework aiguille ensuite sur la vue correspondante.

OK là dessus. J'avais mal compris ton précédent message je croyais que tu disais que Struts retournait des valeurs via les exceptions.

C'est un choix comme un autre, mais dans le cas par exemple de requêtes Ajax (pas gérées par struts 1) on est obligé d'écrire le flux soi même et de retourner NULL, ce qui n'est pas forcément super élégant.

En quoi ce n'est pas élégant ?
Le type de retour indique la page à utiliser pour afficher la vue, et null indique que tu ne souhaites pas en utiliser. Je ne vois pas ce qu'il y a de mal là dedans...

Je trouve la manière de faire de play plus "épurée" puisque: pas d'Action Forward à remplir et à retourner: c'est la méthode renderXXX qu'on aura décidé d'invoquer ou non qui va définir la suite du processus, géré par le framework. C'est d'ailleurs en me questionnant sur cette façon de faire "magique" que j'ai vu qu'ils utilisaient cette astuce sur les exceptions dans le code source du framework.

Je ne connais pas le framework Play et son déroulement exact. Mais je ne comprend pas l'intérêt d'utiliser les exceptions pour des cas standard

a++