Effectivement, je n'aurai pas du utiliser correct: disons une sémantique qui garantie un minimum de sécurité, c'est à dire que la sémantique formelle correspond à l'intuition. Lorsque ce n'est pas le cas (comme en C++ ou autres), on peut écrire du code qui a du sens (probablement), mais pas forcément le sens auquel on s'attend, d'où un bug potentiel.
Si j'ai bien compris, les "conditions" de Rust, fonctionnent comme une sorte de callback: on définit une condition d'erreur C, et lorsqu'une fonction X rencontre une erreur, elle appelle C en donnant le contexte de l'erreur. Ailleurs dans la pile d'appel de X, une autre fonction va recevoir le message de C (ou bien échouer lamentablement si aucune fonction n'a préciser qu'elle voulait intercepter C) et va pouvoir faire deux choses: exécuter du code (par exemple ajouter un message d'erreur à une liste) et renvoyer une valeur par défaut/sûre/témoins. Le code va retourner à X qui va recevoir de la part C la valeur en question et continuer. La doc est très bien faites donc je ne vais pas répéter l'exemple. Mais informellement, la valeur retournée par C va indiquer à X l'action qu'il doit effectuer: par exemple abandonner le traitement, ou poursuite avec une valeur "sentinelle" (-1), ignore cette tâche (une ligne d'un fichier), etc. Mais le point le plus important, c'est que ce n'est pas X qui va choisir l'action (il va seulement l'appliquer), c'est une fonction quelque part dans la pile d'appel, ce qui permet de gérer les erreurs de façon différentes en fonction du contexte. Cela me paraît très souple lorsque c'est bien utilisé, par contre attention à ne pas générer du code incompréhensible !
[^] # Re: De la complexité de la gestion de la mémoire et d'autres
Posté par pamaury . En réponse à la dépêche Présentation de Rust 0.8. Évalué à 1.
Effectivement, je n'aurai pas du utiliser correct: disons une sémantique qui garantie un minimum de sécurité, c'est à dire que la sémantique formelle correspond à l'intuition. Lorsque ce n'est pas le cas (comme en C++ ou autres), on peut écrire du code qui a du sens (probablement), mais pas forcément le sens auquel on s'attend, d'où un bug potentiel.
Si j'ai bien compris, les "conditions" de Rust, fonctionnent comme une sorte de callback: on définit une condition d'erreur C, et lorsqu'une fonction X rencontre une erreur, elle appelle C en donnant le contexte de l'erreur. Ailleurs dans la pile d'appel de X, une autre fonction va recevoir le message de C (ou bien échouer lamentablement si aucune fonction n'a préciser qu'elle voulait intercepter C) et va pouvoir faire deux choses: exécuter du code (par exemple ajouter un message d'erreur à une liste) et renvoyer une valeur par défaut/sûre/témoins. Le code va retourner à X qui va recevoir de la part C la valeur en question et continuer. La doc est très bien faites donc je ne vais pas répéter l'exemple. Mais informellement, la valeur retournée par C va indiquer à X l'action qu'il doit effectuer: par exemple abandonner le traitement, ou poursuite avec une valeur "sentinelle" (-1), ignore cette tâche (une ligne d'un fichier), etc. Mais le point le plus important, c'est que ce n'est pas X qui va choisir l'action (il va seulement l'appliquer), c'est une fonction quelque part dans la pile d'appel, ce qui permet de gérer les erreurs de façon différentes en fonction du contexte. Cela me paraît très souple lorsque c'est bien utilisé, par contre attention à ne pas générer du code incompréhensible !