Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Significations des différents exit() et return()
Bonjour,
Quelqu'un pourrait t'il faire le tour des différents exit() et return() que l'on peut rencontrer et présenter leur utilités car je ne suis pas sure de tous les connaitre et les comprendre.
Comme par exemple, exit(-1), exit(1), exit(0), return 0, return 1, ........
Merci !
exit(cr) --> terminaison de l'exécution d'un processus P (et de tous ses threads) en renvoyant le code retour cr. Ce code retour peut être exploité par le processus ayant lancé P (shell ou utilisateur). La valeur de cr est fonction de tes besoins.
return returnValue
---> pour la fonction main(), génère l'appel à exit().
----> pour une fonction appelée par un mécanisme de call, permet de renvoyer la valeur returnValue (par exemple le résultat d'un calcul) à l'appelant
----> pour une fonction thread, dépend de l'implémentation des threads utilisée (il vaut mieux dans ce cas utiliser l'appel système dédié, par exemple exitThread() )
J'espère que j'ai bien compris la question
Envoyé par joellel
exit(cr) --> terminaison de l'exécution d'un processus P (et de tous ses threads) en renvoyant le code retour cr. Ce code retour peut être exploité par le processus ayant lancé P (shell ou utilisateur). La valeur de cr est fonction de tes besoins.
return returnValue
---> pour la fonction main(), génère l'appel à exit().
----> pour une fonction appelée par un mécanisme de call, permet de renvoyer la valeur returnValue (par exemple le résultat d'un calcul) à l'appelant
----> pour une fonction thread, dépend de l'implémentation des threads utilisée (il vaut mieux dans ce cas utiliser l'appel système dédié, par exemple exitThread() )
J'espère que j'ai bien compris la question
Ok merci,
mais en encore plus simple,
que fait exit(-1), exit(1), exiit(EXIT_FAILURE),....
Quand on fait appel à eux, on sort de la fonction en cours, on sort carément du programme qui du coup s'arette, si on sort de la fonction il faut gerer le retour, ....
Tout appel à exit() termine le programme.
La valeur passée à exit donne le code de retour du programme, 0 ou EXIT_SUCCESS étant considéré comme une "fin normale".
- En Batch, tu peux récupérer ce code avec IF ERRORLEVEL ou la variable %ERRORLEVEL%
- En shell, tu peux généralement dire "faire A, puis B si A a réussi" avec la commande "A && B", La condition "A a réussi" équivalent à "A a retourné EXIT_SUCCESS".
Tu peux également récupérer le code de retour avec la variable $? si je ne me trompe pas.- En C POSIX, tu peux récupérer le code de retour dans une des deux valeurs retournées par wait()/waitpid().
- En C Win32, tu peux récupérer le code de retour avec GetExitCodeProcess().
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
return
return est une instruction.
return; interrompt l'exécution de la fonction courante.
return x; interrompt l'exécution de la fonction courante et retourne une valeur à la fonction appelante qui peut ou non la récupérer.
La valeur retournée dépend de l'application. Souvent, 0 signifie OK, et une autre valeur signifie erreur. Mais c'est purement conventionnel.
exit()
exit() est une fonction.
exit(valeur); interrompt l'exécution d'un programme et retourne une valeur au système.
La valeur retournée dépend du système. Les valeurs portables sont :
- 0 (OK)
- EXIT_SUCCESS (<stdlib.h> : OK)
- EXIT_FAILURE (<stdlib.h> : ERREUR)
Il peut y avoir d'autres valeurs. Elle sont spécifiées dans la doc de programmation du système (par exemple MS-DOS : 0-255).
L'utilisation d'une valeur non spécifiée entraine un comportement indéfini.
Cas particulier : return dans main()
return valeur; se comporte exactement comme exit(valeur);
Merci bien, génial j'ai tout ce qu'il me fallait dans vos réponse.
J'en connaisser une partie mais pas tout, ca fait du bien d evoir ca en claire et en résumé.
Petite précision, dans mon cas je travail dans de l'embarqué et je fais un daemon (qui doit donc tourner en permanence), donc il faut je pense au maximum que je supprime les exit dans mes fonctions pour les remplacer par des return en géreant bien sûr leur retour.
Exemple j'ai une fonction socket d econnection au serveur qui peut renvoyer un exit si la connection se passe mal, il faut donc que je mette un return que je le traite et en cas d'erreur sur le connect que je retourne dans la boucle principal en attente.
Question supplémentaire :
Existe t'il un moyen lorsque l'on est dans une sous fonction du main de revenir directement au main, sans avoir a passer par les fontion intermédiare, en utilisant un return particulier ou autre chose.
Je m'explque, voici le schéma d'un prog :
Main
| -- fonction intermédiaire1
| -- | -- fonction intermédiaire2
| -- | -- | -- fonction intermédiaire3
| -- |
|
Dans ce programme le main doit tourner en boucle en permanence peut importe ce qu'il se passe dans les sous fonction. Jj'ai une gestion d'erreur dans la "fonction intermédiaire3", qui peut me renvoyer 0 (si OK) ou -1 (si erreur). est'il possible si elle me renvoie -1 de revenir direct au main sans avoir besoin d erepasser par la "fonction intermédiaire2" et la "fonction intermédiaire1".
C'est techniquement faisable (setjmp(), longjmp()) mais fortement déconseillé. Le comportement de chaque fonction doit être clair et parfaitement défini. Les court-circuits mène à des situations instables (ressources non libérées etc.)
A merde je pensais pas à ça. Bon ok merci !
Pas tout a fait. exit() appelle en plus les fonctions eventuellement enregistrees aupres de atexit(). Sous certaines plateformes, exit() flush et ferme tous les flux ouverts, et supprime les fichiers crees par tmpfile(). Ces derniers comportements ne sont peut-etre pas standard.
EDIT: return et exit() sont bien equivalents dans main(), voir messages suivants.
Ceci a lieux lorsque le programme se termine donc avec un return (dans le main), il se passe la même chose.
C'est standard :
return dans main() appelle atexit().
Ah oui, tiens:
Merci de cette precision. return et exit() sont donc equivalent dans main(). Je le note.
Moi le pb c'est que si je tente d efaire un return au main en sautant 2 ou 3 fonctions, c'est qu eje ne vais pas d'ésalloue ma mémoire (les free() de mes malloc qui était dans les fonctions intermédiaire).
Il faut que chaque fonction retourne un code d'erreur a la fonction appelante qui gere cette erreur (liberation de la memoire, fermeture des fichiers ouverts, ...). L'erreur remonte jusqu'a main() qui, dans un programme bien concu, est la seule fonction autorisee a terminer le programme (via un return EXIT_FAILURE en cas d'erreur).
C'est assez chiant à gérer car toutes les fonctions sont pas toujours des int, dans ce cas retourner un code erreur de vient plus chiant. si il faut remonter jusqu'au main avec parfois des return(-1) d'autre fois des return(erreur") ou autre ca devient indigerable. ca fait un programme lourd et ps agréable à lire, non ? N'y a t'il pas mieux.
En C, non. Bien concevoir la gestion d'erreur fait partie du jeu. Comme déjà expliqué, un simple 'Go/NoGo' suffit pour commencer (0/1).
Ok je ne m'attendait pas trop a une autre réponse que celle-ci, mais bon fallait demander pour en être sûr.
Go/NoGo, c'est une allusion pour imager ce qu'il faut faire ou c'est un truc du C ? La première je suppose.
J'utilise de plus en plus souvent une variable d'erreur en argument à mes fonctions qui prend comme valeur des constantes d'erreurs créées de toutes pièces bien entendu ... un pau à la façon Glib, ca permet d'avoir toujours comme valeur d'erreur un entier, quelque soit la fonction.
Cette technique permet en plus de savoir quel type d'erreur est soulevée et donc par la même, permet d'afficher un message adequat sur la console ou dans un fichier dans le cas de log d'erreurs (ce que je fait aussi de plus en plus) !
Je pense que cela reste une bonne alternative quant à la gestion des erreurs en C
Mon Site
L'imagination est plus importante que le savoir. A. Einstein
Je ne répond à aucune question technique par MP, merci d'avance !
Oui.
Répondre avec citation
Partager