• [^] # Re: Liberté de l'utilisateur

    Posté par (site web personnel) . En réponse au journal Gestion de l'erreur - C++ - std::optional. Évalué à 4.

    Ça serait vrai si la gestion des erreurs par les optional était une solution universelle et consensuelle. Personnellement, j'ai l'impression que ça ressemble à une fausse bonne idée, qui complexifie l'interface et qui impose à l'utilisateur un paradigme de gestion des erreurs qu'il ne maîtrise peut-être pas, qu'il n'apprécie peut-être pas, ou qui n'est peut-être pas pertinent dans le cadre de son projet.

    Je ne vois pas en quoi cela complexifie l'interface ? D'un coté nous avons une interface implicite où les erreurs sont gérées par des valeurs sentinelles ou des flags, où il faut lire la documentation d'une fonction en profondeur pour comprendre son comportement et avoir de la rigueur lors de l'utilisation pour ne pas se tromper et pour laquelle tout le monde réinvente de la gestion d'erreur tous les jours. Un jour le flag de retour est un bool qui vaut true pour ok, false sinon, l'autre jour c'est l'inverse, le troisième jour c'est un int. De l'autre nous avons une fonction dont le prototype te renseigne beaucoup sur son comportement et pour laquelle tu ne peut pas te tromper en l'utilisant. Et la seule complexification de l'interface c'est l'utilisation d'une classe optional contenant deux méthodes, map et bind (non fournies en standard je te l'accorde). On peut aussi utiliser l'approche par exception sur le .value() comme proposée par d'autres.

    Pour le coté consensus, c'est tout de même une approche prise dans de nombreux langages : Rust, Swift, OCaml, Haskell, entre autre... Avec une approche plus ou moins poussée.

    float distance(float x1, float x2, float y1, float y2) {
 return sqrt(square(x2-x1).value() + square(y2-y1).value()).value();
}

    Pourquoi n'as tu pas poussé le vice de ton exemple jusqu'à mettre un optional sur le + pour montrer à quel point les optionals sont complexes ?

    La gestion d'optional n’apparaît que dans les fonctions qui peuvent générer des erreurs, et dans ces fonctions, il faut traiter les erreurs et soit c'est fait avec des optionals, soit avec autre chose, quoi qu'il en soit, cela apparaitra. Soit il n'y a pas d'erreur à traiter, et dans ce cas là pas de problème. Ainsi ta fonction distance qui est toujours définie, sauf en cas de nombre infinis, peut être écrite sans optional. Après si les NotANumber t’embêtes, alors tu pourras mettre des optionals pour protéger.