Différences entre les versions de « Programmation C/Erreurs »

m
Lorsqu'on veut utiliser <code>errno</code> pour déterminer la cause d'un échec, il faut d'abord s'assurer que la fonction a bel et bien échoué. Le C laissant une certaine liberté dans la manière de signaler un échec, il n'y a pratiquement aucun mécanisme universel qui permette de détecter une telle situation, chaque fonction étant presque un cas particulier. Cepandant, une pratique relativement répandue est de retourner un code spécifique, en général en dehors de l'intervalle de ce qu'on attend. Par exemple, lorsque la fonction est censée allouer un objet et retourne un pointeur, une erreur est souvent signalée en retournant le pointeur générique <code>NULL</code>, et la variable <code>errno</code> décrit plus en détail la nature de l'erreur.
 
Une fois qu'on est sûr que la variable <code>errno</code> contient une valeur pertinente, il est indispensable de présenter un message tout aussi significatif à l'utilisateur. Rien n'est plus frustrant qu'un message aussi abscons que : "<code>fopen("/tmp/tmpab560f9d4", "w") : erreur 28</code>", alors qu'écrit sous la forme&nbsp;: "<code>impossible de créer le fichier temporaire/tmp/tmpab560f9d4: plus de place disponible sur le périphérique</code>", c'est tout de suite nettement plus pertinent.
 
Énumérer toutes les valeurs possibles d'<code>errno</code> peut être relativement pénible, surtout si on doit le faire dans chaque application. Heureusement qu'une fonction toute prête existe&nbsp;:
605

modifications