Je ne fais pas de C++ mais vu ce que tu écris je suis d'accord avec ton constat. Un optional avec une méthode de test et de déréférencement n'apporte pas grand chose à retourner possiblement null. Les deux sont vérifiables avec une analyseur statique de code et les deux permettent de faire des erreurs... Et au passage si tu es dans un langage ou le compilo/runti,e ne peut pas virer l'optional et bien tu viens de prendre un accès mémoire en plus...
D'ailleurs bien que l'Optional de Java soit loin d'être puissant ou génial, c'est un des premier truc que j'explique aux gens. Si tu utilises isPresent() suivi d'un get() alors tu fais certainement une erreur car tu n'as rien gagné du tout. Les API fonctionnelles elles empêchent toute erreur.
Sur le sujet des différents types de gestions d'erreur et les approches des différents langages, je me souviens de cet excellent article: The error model
# Ouai bof
Posté par ckyl . En réponse au journal Gestion de l'erreur - C++ - std::optional. Évalué à 5.
Je ne fais pas de C++ mais vu ce que tu écris je suis d'accord avec ton constat. Un optional avec une méthode de test et de déréférencement n'apporte pas grand chose à retourner possiblement null. Les deux sont vérifiables avec une analyseur statique de code et les deux permettent de faire des erreurs... Et au passage si tu es dans un langage ou le compilo/runti,e ne peut pas virer l'optional et bien tu viens de prendre un accès mémoire en plus...
D'ailleurs bien que l'
Optionalde Java soit loin d'être puissant ou génial, c'est un des premier truc que j'explique aux gens. Si tu utilisesisPresent()suivi d'unget()alors tu fais certainement une erreur car tu n'as rien gagné du tout. Les API fonctionnelles elles empêchent toute erreur.Sur le sujet des différents types de gestions d'erreur et les approches des différents langages, je me souviens de cet excellent article: The error model