Devrions-nous utiliser exit () en C?

Oui, il est correct d'utiliser exit en C.

Pour s'assurer que tous les tampons et gracieux arrêt, il serait recommandé d'utiliser cette fonction atexit, plus d'informations sur ce ici

Un exemple de code serait comme ceci:

void cleanup(void){
   /* example of closing file pointer and free up memory */
   if (fp) fclose(fp);
   if (ptr) free(ptr);
}

int main(int argc, char **argv){
   /* ... */
   atexit(cleanup);
   /* ... */
   return 0;
}

Maintenant, chaque fois que exit est appelée, la fonction cleanup sera exécutée, ce qui peut contenir un arrêt gracieux, un nettoyage des tampons, de la mémoire, etc.

Vous n'avez pas de constructeurs et de destructeurs mais vous pourriez avoir resources (par exemple, fichiers, flux, sockets) et il est important de les fermer correctement. Un tampon n'a pas pu être écrit de manière synchrone, donc quitter le programme sans fermer correctement la ressource en premier, pourrait entraîner une corruption.

Utiliser exit() est OK

Deux aspects majeurs de la conception du code qui n'ont pas encore été mentionnés sont le "threading" et les "bibliothèques".

Dans un programme mono-thread, dans le code que vous écrivez pour implémenter ce programme, l'utilisation de exit() est correcte. Mes programmes l'utilisent régulièrement quand quelque chose a mal tourné et que le code ne va pas se rétablir.

Mais ...

Cependant, appeler exit() est une action unilatérale qui ne peut pas être annulée. C'est pourquoi 'Threading 'et ' bibliothèques' nécessite une réflexion approfondie.

Programmes filetés

Si un programme est multi-thread, l'utilisation de exit() est une action dramatique qui termine tous les threads. Il sera probablement inapproprié de quitter l'ensemble du programme. Il peut être approprié de quitter le thread, en signalant une erreur. Si vous êtes conscient de la conception du programme, alors peut-être que la sortie unilatérale est autorisée, mais en général, ce ne sera pas acceptable.

Code de la bibliothèque

Et ça la clause "consciente de la conception du programme" s'applique également au code dans les bibliothèques. Il est très rarement correct pour une fonction de bibliothèque à usage général d'appeler exit(). Vous seriez à juste titre contrarié si l'une des fonctions de bibliothèque C standard ne parvenait pas à retourner juste à cause d'une erreur. (Évidemment, les fonctions comme exit(), _Exit(), quick_exit(), abort() sont intention de ne pas revenir; c'est différent.) Les fonctions de la bibliothèque C sont donc "impossible d'échouer" ou renvoient une indication d'erreur d'une manière ou d'une autre. Si vous êtes écriture de code pour entrer dans une bibliothèque à usage général, vous devez examiner attentivement la stratégie de gestion des erreurs de votre code. Il devrait s'adapter aux stratégies de gestion des erreurs des programmes avec lesquels il est destiné à être utilisé, ou la gestion des erreurs peut être configurable.

J'ai une série de fonctions de bibliothèque (dans un paquet avec l'en-tête "stderr.h", un nom qui marche sur la glace mince) qui sont destinées à sortir car elles sont utilisées pour les rapports d'erreurs. Ces fonctions sortent par conception. Y sont une série connexe de fonctions dans le même package qui signalent des erreurs et ne sortent pas. Les fonctions sortantes sont implémentées en termes de fonctions non-sortantes, bien sûr, mais c'est un détail d'implémentation interne.

J'ai beaucoup d'autres fonctions de bibliothèque, et un bon nombre d'entre elles s'appuient sur le code "stderr.h" pour les rapports d'erreurs. C'est une décision de conception que j'ai prise et qui me convient. Mais lorsque les erreurs sont signalées avec les fonctions qui sortent, cela limite le général utilité le code de la bibliothèque. Si le code appelle les fonctions de rapport d'erreur qui ne sortent pas, alors les chemins de code principaux dans la fonction doivent traiter les retours d'erreur sanely-les détecter et relayer une indication d'erreur au code appelant.

Le code de mon paquet de rapport d'erreur est disponible dans mon dépôtSOQ (Stack Overflow Questions) sur GitHub en tant que fichiers stderr.c et stderr.h dans le sous-répertoiresrc/libsoq .

Une raison d'éviter exit dans des fonctions autres que main() est la possibilité que votre code soit sorti de son contexte. Rappelez-vous, exit est un type de flux de contrôle non local . Comme des exceptions insaisissables.

Par exemple, vous pouvez écrire certaines fonctions de gestion du stockage qui se terminent sur une erreur de disque critique. Puis quelqu'un décide de les déplacer dans une bibliothèque. Sortir d'une bibliothèque est quelque chose qui entraînera la sortie du programme appelant dans un état inconscient ce qui peut de ne pas être préparé pour.

, Ou vous pouvez l'exécuter sur un système embarqué. Il n'y a pas de sortie à, le tout s'exécute dans un while(1) boucle main(). Il peut même ne pas être défini dans la bibliothèque standard.

Selon ce que vous faites, exit peut être le moyen le plus logique de sortir D'un programme en C. Je sais que c'est très utile pour vérifier que les chaînes de callbacks fonctionnent correctement. Prenez cet exemple de rappel que j'ai utilisé récemment:

unsigned char cbShowDataThenExit( unsigned char *data, unsigned short dataSz,unsigned char status)
{

    printf("cbShowDataThenExit with status %X (dataSz %d)\n", status, dataSz);
    printf("status:%d\n",status);
    printArray(data,dataSz);
    cleanUp();
    exit(0);
}

Dans la boucle principale, j'ai tout configuré pour ce système, puis j'attends dans une boucle while (1). Il est possible de créer un drapeau global pour quitter la boucle while à la place, mais c'est simple et fait ce qu'il doit faire. Si vous avez affaire à des tampons ouverts comme fichiers et périphériques vous devez les nettoyer avant la fermeture pour plus de cohérence.

C'est terrible dans un grand projet quand n'importe quel code peut sortir sauf pour coredump. Trace est très import pour maintenir un serveur en ligne.