• [^] # Re: Je pense que tu confonds les cas où c'est nécessaire

    Posté par (site web personnel) . En réponse au journal Genèse d'un journal. Évalué à 1.

    Le problème, c'est justement comme tu le dis si bien, la PLUPART des appels retourne des codes de retour en C, quasiment jamais vérifié, et que tu devrais toi aussi retourner du coup un code d'erreur.
    Ton code, ça va bien quand t'as 1 appel (et encore, le goto, c'est mal…). Mais je fais quoi quand j'empile 3, 4, 10, 42 appels ?
    Tes 5-10s se transforment en 5-10min puis 5-10j puis 5-10mois, puis… Et faut aussi inclure le coût de la maintenance et des évolutions futures.

    int fooBar() {
     if (foo()) {
     goto clean1;
     }
     if (bar()) {
     goto clean2;
     }
     return 0;
     clean1:
     cleanFoo(); // Merdeuuuuuuuuuuu, je peux planter aussi…
     return -1;
     clean2:
     cleanBar(); // Remerdeuuuuuuuuu, je peux planter aussi…
     return -1;
    }
    
    

    C'est moche, c'est inmaintenable, c'est soumis à une palanqué de possibilité de bugs, ça fait du code spaghetti, ça fait qu'on perd à chaque fois la possibilité de retourner des valeurs non code d'erreur et donc qu'on doit se taper des passages par référence partout…
    Et on ne sait généralement pas quoi faire sinon faire arrêter le programme de manière très moche dès qu'un truc retourne un truc non nul.

    On n'a aucune certitude que notre programme fonctionnera correctement sauf à écrire du code considéré comme ignoble par tout développeur standard.
    Et au final tout le monde s'en contre-fou de ces codes de retour, conduisant à des applis qui plantent/fuitent/buggent !