[Nouveau] gérer des codes d'erreurs

Le 4/09/06 15:36, dans
<1hl5cff.1cud38i1izx1c9N%pere.noel@laponie.com.invalid>, « Une bévue »
<pere.noel@laponie.com.invalid> a écrit :

nouveau en C je ne sais trop comment gérer de codes d'erreurs.

ce que je souhaite|projette de faire :

avoir une sorte de hash table du style :

0 => "Pas d'erreur"
1 => "Problème d'allocation mémoire"
2 => "Fichier inexistant"
etc...

donc comme mon extension C pour Ruby retourne un objet ruby je souhaite
ajouter, par exemple une fonction du type "errno" et une autre "errmsg"
cette dernière donnant - en clair - le mesage d'erreur en anglais (je
n'envisage pas d'internationalisation).

y a t'il un tuto qqpart sur ce sujet ?

Un bouquin sur le C ?


En C standard on sort, d'une façon normale, du programme par un "return x"
dans le main ou par un "exit(x)". Le "x" peut avoir 3 valeurs : 0,
EXIT_SUCCESS et EXIT_FAILURE. Les 2 premières sont équivalentes. Il n'y a
pas d'autres codes possibles de façon standard.

Sous Unix, la valeur "x" est plus libre et vaut typiquement un nombre entre
0 et 255. La valeur n'est pas libre, même si c'est un "int" (là encore
typiquement 32 bits), par ce que vu du père, le "x" est un champ de bits
dont certains indiquent la mort du fils par un signal. Les macros pour
manipuler le "x" sont du type WEXITSTATUS (man 2 wait).

Ensuite si tu veux passer du texte il y a 2 flux standards : stdout et
stderr. Et là aussi, typiquement, on place les messages d'erreur dans
stderr.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

Eric Levenez wrote:

En C standard on sort, d'une façon normale, du programme par un "return x"
dans le main ou par un "exit(x)". Le "x" peut avoir 3 valeurs : 0,

Je pense qu'il parlait de codes d'erreur au retour des fonctions. Pas de
codes d'erreur de fin du programme. Surtout s'il travaille sur une
extension Ruby, donc une bibliothèque ...

--
Hamiral

Eric Levenez <news@levenez.com> wrote:

Un bouquin sur le C ?

je vais m'en payer un, mais lequel ???
en tk ma consultation de divers site cité en référence me laisse
perplexe, bien des tutos sont peu fiables même quand leurs exemples
compilent.
sur le net, pour l'instant, je n'ai pas trouvé d'exemple d'alloc mem
pour un tableau qui soit vraiment probant.
le seul que j'ai trouvé a fait hurler Luc )))

En C standard on sort, d'une façon normale, du programme par un "return x"
dans le main ou par un "exit(x)". Le "x" peut avoir 3 valeurs : 0,
EXIT_SUCCESS et EXIT_FAILURE. Les 2 premières sont équivalentes. Il n'y a
pas d'autres codes possibles de façon standard.

aille ça m'embête cette version C standard j'aimerais mieux avoir Deux
codes d'exit

Sous Unix, la valeur "x" est plus libre et vaut typiquement un nombre entre
0 et 255. La valeur n'est pas libre, même si c'est un "int" (là encore
typiquement 32 bits), par ce que vu du père, le "x" est un champ de bits
dont certains indiquent la mort du fils par un signal. Les macros pour
manipuler le "x" sont du type WEXITSTATUS (man 2 wait).

en fait j'ai regardé de plus près ce dont j'ai besoin, j'ai deux cas qui
justifient un exit anormal:

- allocation mémoire pas OK => EXIT_FAILURE
- le cas où le path filé en entrée ne correspond à rien dans le file
system => inutile de continuer

Ensuite si tu veux passer du texte il y a 2 flux standards : stdout et
stderr. Et là aussi, typiquement, on place les messages d'erreur dans
stderr.

ouais, grosso-modo c'est un peu comme en shell.
--
une bévue

Hamiral <hamiral@hamham.fr> wrote:

Je pense qu'il parlait de codes d'erreur au retour des fonctions. Pas de
codes d'erreur de fin du programme. Surtout s'il travaille sur une
extension Ruby, donc une bibliothèque ...

exact car ce que retourne ma fonction c'est un instance d'objet ruby ça
me donne une idée : en cas d'une erreur imparable (pb alloc mémoire) je
retourne Qnil, ça a l'avantage d'interdire à l'utilisateur de continuer
d'utiliser cette instance d'objet.

dans ce cas j'envoie sur stderr un message en clair.

dans les autres cas le prog se termine normalement avec un errno != 0 et
un errmsg.

le cas où l'utilisateur a entré un path inexistant "physiquement" dans
le file system me pose problème.

en fait dans mon prog C je n'ai qu'une fonction "réelle" les autres
étant des setters|getters (come on dit en Java) qu'on ne peut utiliser
qu'à condition d'avoir retourné un objet non null (Qnil en C ext to
ruby). je n'ai qu'une méthode singleton c'est #version.

donc (je réfléchis tout haut) dans le cas d'un path inexistant, je peux
retourner un objet + un message d'erreur sur stderr car je souhaite
avoir le moins possible de sortie bloquante par exit(1).

reste à l'utilisateur de consulter #errno et #errmsg...
--
une bévue

Le 4/09/06 19:53, dans
<1hl5mk1.t9i34s6eyx9bN%pere.noel@laponie.com.invalid>, « Une bévue »
<pere.noel@laponie.com.invalid> a écrit :

Eric Levenez <news@levenez.com> wrote:

Un bouquin sur le C ?

je vais m'en payer un, mais lequel ???

Prends déjà le premier cité dans la FAQ §3.9/

en tk ma consultation de divers site cité en référence me laisse
perplexe, bien des tutos sont peu fiables même quand leurs exemples
compilent.
sur le net, pour l'instant, je n'ai pas trouvé d'exemple d'alloc mem
pour un tableau qui soit vraiment probant.
le seul que j'ai trouvé a fait hurler Luc )))

Il n'y a pas que Luc pour hurler sur ta façon d'appréhender la programmation
et le langage C. :-/

En C standard on sort, d'une façon normale, du programme par un "return x"
dans le main ou par un "exit(x)". Le "x" peut avoir 3 valeurs : 0,
EXIT_SUCCESS et EXIT_FAILURE. Les 2 premières sont équivalentes. Il n'y a
pas d'autres codes possibles de façon standard.

aille ça m'embête cette version C standard j'aimerais mieux avoir Deux
codes d'exit

Pas en C standard.

Sous Unix, la valeur "x" est plus libre et vaut typiquement un nombre entre
0 et 255. La valeur n'est pas libre, même si c'est un "int" (là encore
typiquement 32 bits), par ce que vu du père, le "x" est un champ de bits
dont certains indiquent la mort du fils par un signal. Les macros pour
manipuler le "x" sont du type WEXITSTATUS (man 2 wait).

en fait j'ai regardé de plus près ce dont j'ai besoin, j'ai deux cas qui
justifient un exit anormal:

- allocation mémoire pas OK => EXIT_FAILURE
- le cas où le path filé en entrée ne correspond à rien dans le file
system => inutile de continuer

Ceci est possible sous Unix, mais ce n'est plus du C standard, c'est Posix
par contre.

Ensuite si tu veux passer du texte il y a 2 flux standards : stdout et
stderr. Et là aussi, typiquement, on place les messages d'erreur dans
stderr.

ouais, grosso-modo c'est un peu comme en shell.

Le shell est juste un programme comme les autres, il se conforme donc
lui-même au principe du système.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

Le 4/09/06 18:44, dans <44fc5803$0$21144$7a628cd7@news.club-internet.fr>,
« Hamiral » <hamiral@hamham.fr> a écrit :

Eric Levenez wrote:

En C standard on sort, d'une façon normale, du programme par un "return x"
dans le main ou par un "exit(x)". Le "x" peut avoir 3 valeurs : 0,

Je pense qu'il parlait de codes d'erreur au retour des fonctions. Pas de
codes d'erreur de fin du programme.

Ah, ok, alors j'ai rien dit.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

Eric Levenez <news@levenez.com> wrote:

je vais m'en payer un, mais lequel ???

Prends déjà le premier cité dans la FAQ §3.9/

OK fastoche ))

en tk ma consultation de divers site cité en référence me laisse
perplexe, bien des tutos sont peu fiables même quand leurs exemples
compilent.
sur le net, pour l'instant, je n'ai pas trouvé d'exemple d'alloc mem
pour un tableau qui soit vraiment probant.
le seul que j'ai trouvé a fait hurler Luc )))

Il n'y a pas que Luc pour hurler sur ta façon d'appréhender la programmation
et le langage C. :-/

ah bon même aussi fort que lui ???

il n'empèche que mes exemples ne sont pas sortis d'un chapeau, je les ai
bien pris qqpart...
--
une bévue

Le 4/09/06 19:53, dans
<1hl5muv.1907bjyykqui9N%pere.noel@laponie.com.invalid>, « Une bévue »
<pere.noel@laponie.com.invalid> a écrit :

Hamiral <hamiral@hamham.fr> wrote:

Je pense qu'il parlait de codes d'erreur au retour des fonctions. Pas de
codes d'erreur de fin du programme. Surtout s'il travaille sur une
extension Ruby, donc une bibliothèque ...

exact car ce que retourne ma fonction c'est un instance d'objet ruby ça
me donne une idée : en cas d'une erreur imparable (pb alloc mémoire) je
retourne Qnil, ça a l'avantage d'interdire à l'utilisateur de continuer
d'utiliser cette instance d'objet.

Donc tu parles du code d'erreur d'une fonction C, et pas d'un programme.

Ok alors il y a différentes traditions. Voici quelques exemples

Si une fonction retourne un entier, alors une valeur particulière indique
une erreur (genre 0 ou -1) et les autres une valeur normale.

Si une fonction doit retourner un pointeur, alors elle retourne NULL en cas
d'erreur et une autre valeur en cas de succès.

Les fonctions systèmes retournent typiquement -1 en cas d'erreur et
positionnent une variable globale errno qui est positionnée en cas d'erreur
(variable pas touchée si fonction ok). Il est de tradition aussi de ne
jamais faire une fonction utilisateur sur ce principe. En fait errno n'est
pas forcément une variable, cela peut être une fonction, une macro, une
expression... Donc on laisse le système s'occupé de errno

Pour les fonctions utilisateurs, au lieu de coder dans le code de retour une
erreur et une valeur, on utilise de plus en plus un code du type :

int fct(int in1, char *in2, int *out1, char **out2);

La fonction a 2 paramètres en sorties que la fonction initialisera. Ils sont
donc passés par des pointeurs. La fonction retourne juste 0 ou 1 pour
indiquer qu'elle s'est bien passée ou non. Les valeurs retournées sont dans
des pointeurs.

dans ce cas j'envoie sur stderr un message en clair.

Oui, une fonction peut afficher sur stderr un message d'erreur, mais une
fonction générique n'affiche rien. C'est le programme appelant qui fait
l'affichage;

dans les autres cas le prog se termine normalement avec un errno != 0 et
un errmsg.

Un programme ? Mais je croyais que tu parlais de fonction. :-/

"errno" est normalement réservé aux fonctions systèmes.

le cas où l'utilisateur a entré un path inexistant "physiquement" dans
le file system me pose problème.

en fait dans mon prog C je n'ai qu'une fonction "réelle" les autres

Je comprends plus rien. Maintenant tu parles _vraiment_ d'un programme :-/

étant des setters|getters (come on dit en Java) qu'on ne peut utiliser
qu'à condition d'avoir retourné un objet non null (Qnil en C ext to
ruby). je n'ai qu'une méthode singleton c'est #version.

La tu parles de méthode. C'est une "fonction" l'Objective-C ou autre ou
est-ce vraiment un programme ?

donc (je réfléchis tout haut)

Oui, je vois bien que tout n'est pas clair et que si tu construisait d'abord
clairement ta question, la réponse que nous pourrions te donner serait plus
claire elle-aussi.

dans le cas d'un path inexistant, je peux
retourner un objet + un message d'erreur sur stderr car je souhaite
avoir le moins possible de sortie bloquante par exit(1).

Exit c'est pour sortir d'un programme, pas d'une fonction.

reste à l'utilisateur de consulter #errno et #errmsg...

Pas vraiment.

Je suis largué sur ce que tu veux faire. C'est pas clair du tout. Luc où
es-tu ?

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

Une bévue wrote:

Hamiral <hamiral@hamham.fr> wrote:

Je pense qu'il parlait de codes d'erreur au retour des fonctions. Pas de
codes d'erreur de fin du programme. Surtout s'il travaille sur une
extension Ruby, donc une bibliothèque ...

exact car ce que retourne ma fonction c'est un instance d'objet ruby ça
me donne une idée : en cas d'une erreur imparable (pb alloc mémoire) je
retourne Qnil, ça a l'avantage d'interdire à l'utilisateur de continuer
d'utiliser cette instance d'objet.

dans ce cas j'envoie sur stderr un message en clair.

Et bien dans ce cas, fais que ta fonction retourne ton objet ruby, et en cas
d'erreur :
- retourne Qnil
- positionne une variable globale avec un code d'erreur (mais pas errno,
comme dit par d'autres, c'est réservé par stdlib)
- il te faut aussi une petite fonction, qui, en fonction du code d'erreur,
retourne une chaîne de caractères contenant le message d'erreur adéquat,
mais ne l'affiche pas, en effet ce n'est pas aux fonctions utilitaires de
faire cela. Tu peux être amené à vouloir afficher ce message d'erreur dans
une boîte de dialogue plutôt que sur stdout ou stderr par exemple ...

dans les autres cas le prog se termine normalement avec un errno != 0 et
un errmsg.

le cas où l'utilisateur a entré un path inexistant "physiquement" dans
le file system me pose problème.

A partir de là tu embrouilles tout le monde : tu commences à penser en Ruby
à haute voix, alors qu'ici on ne sait parler que le C ... :)


--
Hamiral

Eric Levenez wrote:

dans ce cas j'envoie sur stderr un message en clair.

Oui, une fonction peut afficher sur stderr un message d'erreur, mais
une fonction générique n'affiche rien. C'est le programme appelant qui
fait l'affichage;

De plus, envoyer des messages sur stderr n'est valable que dans les cas
particuliers où on ne tourne pas comme daemon.

Amha, une fonction 'générique ' ou non est définissable par son API, il
y a des cas où des fonctions de bibliothèque, notamment en mode Debug,
peuvent envoyer des messages sur stderr, le reste du temps c'est
inconenant et rend ces fonctions inutilisables, parce que des fonctions
qui testent si stderr est ouvert avant d'y balancer un message, on n'en
voit pas tous les jours !
Par contre, elles rattrappent l'exception et envoient un message sur
stderr pour nous en avertir...

--
http://patrick.davalan.free.fr/