• [^] # Re: Une gestion d’erreur moderne ?

    Posté par (site web personnel) . 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 ?

    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.

    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 :

    • en Go, tu dois ajouter du code pour traiter l'erreur
    • en Rust, tu dois ajouter du code pour ignorer l'erreur

    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 :

    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