Merci pour cette présentation claire de l'état de l'art sur la gestion des erreurs. En fait, j'ai quand même l'impression que ce domaine est peut-être l'un de ceux où les langages de programmation ont le plus de marge de progression. En particulier, il s'agit toujours d'un compromis entre la souplesse et la robustesse, entre une approche quasiment mathématique (obligation de gérer toutes les causes d'échec) et une approche pragmatique.
Par exemple, ce qui me gène pas mal avec std::optional, c'est qu'on impose à l'utilisateur une syntaxe particulière (en gros, on reporte sur l'utilisateur le traitement des erreurs). L'autre problème, c'est qu'il ne semble pas facile de distinguer les "warnings" (du style "attention, il y a quelque chose qui ne se passe pas comme prévu") et les erreurs ("la valeur de retour n'a pas de sens").
Honnêtement, le meilleur système que j'ai trouvé pour les projets de taille moyenne (code scientifique principalement destiné à tourner en "interne", ne doit pas faire n'importe quoi mais pas d'aspect critique—en particulier, mieux vaut planter que de rester dans un état douteux), c'est la logique de certains langages interprétés, où les fonctions peuvent retourner quelque chose comme "NA" et/ou émettre des warnings, ce qui fait que le code n'est jamais dans un état réelement indéterminé (au pire, f(NA) renvoie NA). Du coup, on peut développer sans se prendre la tête avec le traitement des erreurs, et on peut ratrapper le coup à n'importe quel niveau. Le côté négatif, évidemment, c'est que l'erreur n'est pas identifiée clairement par le code de retour, et que les détails sont dans stderr, donc plus ou moins inaccessibles au programme.
# Liberté de l'utilisateur
Posté par arnaudus . En réponse au journal Gestion de l'erreur - C++ - std::optional. Évalué à 2.
Merci pour cette présentation claire de l'état de l'art sur la gestion des erreurs. En fait, j'ai quand même l'impression que ce domaine est peut-être l'un de ceux où les langages de programmation ont le plus de marge de progression. En particulier, il s'agit toujours d'un compromis entre la souplesse et la robustesse, entre une approche quasiment mathématique (obligation de gérer toutes les causes d'échec) et une approche pragmatique.
Par exemple, ce qui me gène pas mal avec std::optional, c'est qu'on impose à l'utilisateur une syntaxe particulière (en gros, on reporte sur l'utilisateur le traitement des erreurs). L'autre problème, c'est qu'il ne semble pas facile de distinguer les "warnings" (du style "attention, il y a quelque chose qui ne se passe pas comme prévu") et les erreurs ("la valeur de retour n'a pas de sens").
Honnêtement, le meilleur système que j'ai trouvé pour les projets de taille moyenne (code scientifique principalement destiné à tourner en "interne", ne doit pas faire n'importe quoi mais pas d'aspect critique—en particulier, mieux vaut planter que de rester dans un état douteux), c'est la logique de certains langages interprétés, où les fonctions peuvent retourner quelque chose comme "NA" et/ou émettre des warnings, ce qui fait que le code n'est jamais dans un état réelement indéterminé (au pire, f(NA) renvoie NA). Du coup, on peut développer sans se prendre la tête avec le traitement des erreurs, et on peut ratrapper le coup à n'importe quel niveau. Le côté négatif, évidemment, c'est que l'erreur n'est pas identifiée clairement par le code de retour, et que les détails sont dans stderr, donc plus ou moins inaccessibles au programme.