Retourner au contenu associé (dépêche : À la découverte du langage V)
Posté par David Delassus (site web personnel) le 06 septembre 2023 à 16:08. En réponse à la dépêche À la découverte du langage V. Évalué à 4.
Non, c'est une interface
My bad, je le savais en plus, mais j'ai vu tellement de codebases Go ou c'était juste des strings que j'ai fait un raccourci un peu trop rapide.
Est-ce que faire un unwrap, ça compte vraiment comme traiter l'erreur ?
unwrap
Oui car unwrap sur un Result::Err(E) ça panic!. Alors que ne pas faire de if err != nil en Go, le programme continu comme si de rien n'était.
Result::Err(E)
panic!
if err != nil
Dans les deux cas, on ignore explicitement l'erreur sans la traiter.
Ben non :
func foo() (something, error) { a, err := bar() // pas de if err != nil // beaucoup de code }
La c'est pas explicite du tout.
Alors qu'en Rust :
ifletOk(a)=bar(){ // ... } // ou matchbar(){ Ok(a)=>{/* ... */}, _=>{} }
En gros :
Perso, je trouve la gestion des erreurs en Go assez bof, mais pas atroce non plus.
Chacun ses goûts. Pour ma part, je défend l'idée que "fournir un type/interface 'error'" ce n'est pas de la gestion d'erreur.
En fait, je ne vois même pas de différence avec le C dans ce cas là :
int foo(); // retourne 0 en cas de succès, -1 en cas d'erreur
Au moins, la GLib (pas gnu libc, mais bien GLib de GTK), on a GError et compagnie :
GError
bool foo(GError **err); // true en cas de succès, false en cas d'erreur // si erreur, et que err != NULL, on propage l'erreur dans *err
Verbeux, peu pratique, mais déjà un peu mieux qu'un int.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
AltStyle によって変換されたページ (->オリジナル) / アドレス: モード: デフォルト 音声ブラウザ ルビ付き 配色反転 文字拡大 モバイル
[^] # Re: Une gestion d’erreur moderne ?
Posté par David Delassus (site web personnel) . En réponse à la dépêche À la découverte du langage V. Évalué à 4.
My bad, je le savais en plus, mais j'ai vu tellement de codebases Go ou c'était juste des strings que j'ai fait un raccourci un peu trop rapide.
Oui car
unwrapsur unResult::Err(E)çapanic!. Alors que ne pas faire deif err != nilen Go, le programme continu comme si de rien n'était.Ben non :
La c'est pas explicite du tout.
Alors qu'en Rust :
En gros :
Chacun ses goûts. Pour ma part, je défend l'idée que "fournir un type/interface 'error'" ce n'est pas de la gestion d'erreur.
En fait, je ne vois même pas de différence avec le C dans ce cas là :
Au moins, la GLib (pas gnu libc, mais bien GLib de GTK), on a
GErroret compagnie :Verbeux, peu pratique, mais déjà un peu mieux qu'un int.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg