Re: Une gestion d’erreur moderne ?

Je trouve la gestion d'erreur de Go atroce, pour ne pas dire inexistante.

Le langage ne te force pas à la traiter, rien ne t'empêche d'écrire :

res, _ := foo()

Il peut quand même y avoir des données dans le résultat, même si err est nil :

func foo() (int, error) {
 return 42, errors.New("oops")
}

Dans ce cas, on fait quoi de res ?

Il faut utiliser des modules tiers pour garder les informations qu'une stacktrace d'exception a par défaut, car :

res, err := foo()
if err != nil {
 return whatever, err
}

Ici on pert complètement l'information, la bonne pratique c'est d'encapsuler l'erreur dans une nouvelle, en utilisant par exemple le module xerrors.

Le type error est concrètement juste une chaîne de caractères, sans module tiers tel que xerrors ou autre, impossible de déterminer le type de l'erreur, alors qu'avec une exception, on peut au moins faire du pattern matching sur son type.

---

Au final, je préfère un type monadique, comme std::expected<T, E> en C++ ou Result<T, E> en Rust.

Ici:

• on a bien une valeur OU une erreur
• on est obligé de traiter l'erreur
• on peut faire du pattern matching sur le type de l'erreur et sa valeur
• on sait quel type d'erreur une fonction peut retourner

Les exceptions pourraient être du sucre syntaxique pour un tel type monadique. D'ailleurs, l'opérateur ? en Rust ressemble beaucoup à ça :

fn foo()-> Result<T,E1>{
// ...
}
fn bar()-> Result<T,E2>{
letval=foo()?;
// si foo retourne Result::Err(E1),
// alors bar retourne Result::Err(E2) a condition que E2 implémente From<E1>
// si l'implémentation n'est pas trouvée --> erreur de compilation
}

C'est tout de suite plus propre.

---

TL;DR: Les gens qui vantent les mérites de la gestion d'erreur en Go, je les comprends pas :(

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg