C'est inspirant cette façon de faire des présentations... 1h pour ne pas faire de try catch.
Ce qui est intéressant c'est la volonté de formuler tous les cas de figure pour la gestion d'erreurs et d'y associer une syntaxe.
Ce qui me gène avec cette approche :
l'aspect performance, on ne retourne pas directement un résultat, mais un objet virtuel, qui contient soit le résultat, soit une erreur. C'est un inconvénient par rapport au fait de dissocier le résultat et l'erreur ;
"do or do not, there is no try", j'ai besoin de savoir pourquoi ;
Au final je ne trouve pas forcément la syntax simple ;
Enfin et surtout, la validation des données N'EST PAS une erreur.
En ce qui me concerne, nous utilisons groovy et Java, qui propose avec les enum des possibilités proches. Pour le cas présenter (validation d'un objet, sequence de traitement, gestion des erreurs associées) :
La validation des données nécessite un validator dans la classe implémentant l'objet, aucun cas de gestion de cette aspect n'apparait dans le code métier, c'est le FW qui décore les actions pour retourner l'information à l'utilisateur ;
Le reste sont des exceptions.
Les exceptions constituent les erreurs non prévisibles, comme un problème réseau, disque plein, et d'autres aspect, comme la sécurité. Je comprends mal l'intérêt de ne pas utiliser les exceptions..
[^] # Re: Kamoulox !
Posté par YBoy360 (site web personnel) . En réponse au journal Golang, oops you did it again. Évalué à 5.
C'est inspirant cette façon de faire des présentations... 1h pour ne pas faire de try catch.
Ce qui est intéressant c'est la volonté de formuler tous les cas de figure pour la gestion d'erreurs et d'y associer une syntaxe.
Ce qui me gène avec cette approche :
En ce qui me concerne, nous utilisons groovy et Java, qui propose avec les enum des possibilités proches. Pour le cas présenter (validation d'un objet, sequence de traitement, gestion des erreurs associées) :
Les exceptions constituent les erreurs non prévisibles, comme un problème réseau, disque plein, et d'autres aspect, comme la sécurité. Je comprends mal l'intérêt de ne pas utiliser les exceptions..