Effectivement les exceptions qui ne sont pas rattrapées et remontent implicitement la stack trace ne sont pas une solution satisfaisante. Mais je ne trouve pas que la solution proposée soit plus moderne. Ça ressemble plus à du sucre syntaxique avec des conventions implicites, ce qui le rendent moins lisible pour un novice, ce qui est un mauvais point selon moi.
C'est dommage parce que le langage s'inspire du go dont j'aime beaucoup la gestion d'erreur :
* c'est un type comme un autre, il n'y a pas de notion d'erreur dans la syntaxe du langage, c'est une convention, mais une convention explicite
* la gestion des erreurs est elle aussi explicite : si on veut tester si une erreur a été retournée, on teste si l'erreur est différente de nil. Il n'y a pas de "if" magique qui teste implicitement ce cas. Un "if" fonctionne uniquement avec un booléen.
Ça donne du code plutôt verbeux j'en conviens, mais tout est explicite. Et le fait que ça ne soit pas une feature de la syntaxe du langage fait une feature de moins à apprendre.
Le problème restant, et commun à toutes ces gestions d'erreur, c'est la question de comment savoir quelles erreurs peut retourner une fonction. Pour l'instant peu importe le modèle, je n'ai jamais rien vu de satisfaisant.
PS : je suis allé voir la gestion des erreurs en zig, c'est de l'implicite couplé à la gestion implicite des optional, ça me file la nausée ^
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
# Une gestion d’erreur moderne ?
Posté par erdnaxeli (site web personnel) . En réponse à la dépêche À la découverte du langage V. Évalué à 5.
Effectivement les exceptions qui ne sont pas rattrapées et remontent implicitement la stack trace ne sont pas une solution satisfaisante. Mais je ne trouve pas que la solution proposée soit plus moderne. Ça ressemble plus à du sucre syntaxique avec des conventions implicites, ce qui le rendent moins lisible pour un novice, ce qui est un mauvais point selon moi.
C'est dommage parce que le langage s'inspire du go dont j'aime beaucoup la gestion d'erreur :
* c'est un type comme un autre, il n'y a pas de notion d'erreur dans la syntaxe du langage, c'est une convention, mais une convention explicite
* la gestion des erreurs est elle aussi explicite : si on veut tester si une erreur a été retournée, on teste si l'erreur est différente de nil. Il n'y a pas de "if" magique qui teste implicitement ce cas. Un "if" fonctionne uniquement avec un booléen.
Ça donne du code plutôt verbeux j'en conviens, mais tout est explicite. Et le fait que ça ne soit pas une feature de la syntaxe du langage fait une feature de moins à apprendre.
Le problème restant, et commun à toutes ces gestions d'erreur, c'est la question de comment savoir quelles erreurs peut retourner une fonction. Pour l'instant peu importe le modèle, je n'ai jamais rien vu de satisfaisant.
PS : je suis allé voir la gestion des erreurs en zig, c'est de l'implicite couplé à la gestion implicite des optional, ça me file la nausée ^
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.