• [^] # Re: Survivor

    Posté par (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 5.

    C'est pas joli setjmp/longjmp. Comme disent certains "Exceptions are, in essence, sophisticated GOTO statements".

    Loin de moi l'idée de penser que les exceptions sont mauvaises, mais ça n'a pas sa place dans ce langage aussi bas niveau qu'est le C. En C++ par exemple, un simple std::cout << "hello\n" peut lever une exception ce qui signifie que dans les programmes très critiques il faut absolument lire la documentation de chaque fonction qu'on utilise. Mais aussi, si j'utilise une bibliothèque qui ne documente pas bien les exceptions qu'elle peut lever (car elle en oublie d'une couche plus bas niveau) je risque tout simplement de planter mon programme car j'arriverai dans la gestion de l'exception peut-être là où je ne le souhaite pas. Alors devons nous protéger tous les appels de chaque fonction ?

    On dit aussi que les exceptions sont performantes. Ce n'est pas le cas. Une fois on a réduit drastiquement les performances d'une boucle de notre application qui était écrite de cette manière :

    for (...) {
     try {
     something();
     } catch (...) {
     blabla();
     }
    }

    En

    try {
     for (...) {
     something();
    } catch (...) {
     blabla();
    }

    Certes une erreur d'étourderie. Mais si la fonction something() fait aussi des try-catch à tout va, les performances sont encore une fois impactées.

    Pour ma part j'ai utilisé une seule fois setjmp/longjmp dans mon application (un jeu vidéo). L'idée est de faire un mécanisme de « panic » : s'il arrive quelque chose d'irrécupérable (carte corrompu, image manquante, ...) au lieu de crasher l'application à la sauvage, j'affiche quelque chose à l'écran avant de quitter (un peu comme un BSOD). Mais c'est la seule utilisation viable que j'en ai.

    AI is a mental disorder