Ça me fait un peu penser aux Exceptions (sans les problèmes de sûreté) mais la syntaxe est quand même assez différente et... perturbante. Ça me parait plus souple que les exceptions, mais à voir à l’utilisation.
Si ça ressemble visuellement aux Exceptions, la sémantique est assez différente, puisqu'il manque la fonctionnalité la plus puissante (mais aussi la plus controversée), à savoir la remontée au travers de la pile (et donc des appels de fonctions). En effet dans Rust, le gestionnaire de conditions est exécuté à l'endroit du raise, et ne constitue pas une autre façon de sortir de la fonction.
Bien utilisée, la remontée dans la pile permet d'écrire du code court et d'éviter pas mal de code boilerplate. Malheureusement ce comportement casse la sémantique de Rust, qui ne pourrait plus fournir ses garanties.
Je suis assez sceptique sur l'utilité des conditions, parce que si le discours est qu'on peut coder le comportement que l'on veut face à une erreur, j'ai l'impression qu'il faudrait plus ou moins penser à tous les comportements possibles, afin que la signature du handler permette dans les faits de gérer l'erreur comme on le veut. Je me dis que dans la pratique on va peut-être la plupart du temps finir par gérer l'erreur d'une manière figée et retourner un Option/Result.
Mais j'espère me tromper, et je vais faire confiance aux développeurs de Rust qui ont fait du super boulot pour le reste, donc y a pas de raisons ! Et Rust possède à côté d'autres outils permettant d'éviter le boilerplate.
[^] # Re: De la complexité de la gestion de la mémoire et d'autres
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Présentation de Rust 0.8. Évalué à 4.
Si ça ressemble visuellement aux Exceptions, la sémantique est assez différente, puisqu'il manque la fonctionnalité la plus puissante (mais aussi la plus controversée), à savoir la remontée au travers de la pile (et donc des appels de fonctions). En effet dans Rust, le gestionnaire de conditions est exécuté à l'endroit du raise, et ne constitue pas une autre façon de sortir de la fonction.
Bien utilisée, la remontée dans la pile permet d'écrire du code court et d'éviter pas mal de code boilerplate. Malheureusement ce comportement casse la sémantique de Rust, qui ne pourrait plus fournir ses garanties.
Je suis assez sceptique sur l'utilité des conditions, parce que si le discours est qu'on peut coder le comportement que l'on veut face à une erreur, j'ai l'impression qu'il faudrait plus ou moins penser à tous les comportements possibles, afin que la signature du handler permette dans les faits de gérer l'erreur comme on le veut. Je me dis que dans la pratique on va peut-être la plupart du temps finir par gérer l'erreur d'une manière figée et retourner un Option/Result.
Mais j'espère me tromper, et je vais faire confiance aux développeurs de Rust qui ont fait du super boulot pour le reste, donc y a pas de raisons ! Et Rust possède à côté d'autres outils permettant d'éviter le boilerplate.