Retourner proprement une erreur - Page 1

Que doit-on faire pour retourner proprement une erreur ?
Doit-on mettre un code documenté dans pedrom::errno ?
Doit-on mettre ce code dans d0.w ?
Faut-il appeler kernel::exit pour que l'erreur soit prise en compte comme telle par l'éventuel programme appelant ?
Faut-il pousser une valeur sur l'estack (return value) de 0 si tout s'est bien passé, ou du numéro de l'erreur si il y a eu un problème ?
Y a-t-il des codes d'erreur standard à suivre de préférence ?

Folco (./1) :
Que doit-on faire pour retourner proprement une erreur ?

Voir la suite.

Folco (./1) :
Doit-on mettre un code documenté dans pedrom::errno ?

Non.

Folco (./1) :
Doit-on mettre ce code dans d0.w ?

Si c'est le code de retour de main, on peut.

Folco (./1) :
Faut-il appeler kernel::exit pour que l'erreur soit prise en compte comme telle par l'éventuel programme appelant ?

On peut.

Folco (./1) :
Faut-il pousser une valeur sur l'estack (return value) de 0 si tout s'est bien passé, ou du numéro de l'erreur si il y a eu un problème ?

Non.

Folco (./1) :
Y a-t-il des codes d'erreur standard à suivre de préférence ?

Non.

Ok. Donc on met juste un code dans d0.w et c'est marre.

Et ER_throw?

Jamais utilisé, je regarderai à l'occasion, mais à priori je préfère balancer qqchose sur stdout (puis ça fait plus geek )

stderr plutôt, non ?

Kevin Kofler (./4) :
Et ER_throw?

C'est un autre type d'erreur qui n'est pas récupérable par script.
Mais tu as raison : on peut aussi renvoyer par ER_throw.

Oué stderr... seulement je sais pas y faire... je fais comment ? Je fais toujours des printf, ça va où ? ok, à l'écran... mais sachant que je ne pourrais pas définir stdout et stderr (c'est des pointeurs ? j'ai cru plutôt voir que c'était des flags ?) je me vois mal envoyer à stderr plutôt qu'à stdout.

Voilà, tout ça c'est le gros bordel dans ma tête.

En tout cas, j'espère qu'il faut pas faire

pedrom::system( sprintf( "echo %s 2> %s" , error , pedrom__tmpnam()))
pedrom::system( sprintf( "cat %s | more" , 5+HeapDeref( SymFindPtr( NULL , <tmpfile>)[12])))

mais non, je sais bien que cas ça quand même ^^
C'est que ça coûte cher les appels à pedrom en flash #trisubtil#

Folco (./8) :
Je fais toujours des printf, ça va où ?

Au terminal ouvert (écran) ou dans un fichier. Rien n'empèche de le rediriger vers le link par exemple.

Folco (./8) :
ok, à l'écran...

Pas forcément.

Folco (./8) :
mais sachant que je ne pourrais pas définir stdout et stderr

Ils sont déjà définis.
Regarde pedrom@0000+ quelque chose.

Folco (./8) :
c'est des pointeurs ?

Oui. Des pointeurs vers une structure FILE qui n'est pas documentée.

Folco (./8) :
j'ai cru plutôt voir que c'était des flags ?

Non.

Folco (./8) :
je me vois mal envoyer à stderr plutôt qu'à stdout.

En C, printf (...) est équivalent à fprintf (stdout, ...)
fprintf (stderr, ...) permet d'envoyer sur stderr.

Folco (./8) :
En tout cas, j'espère qu'il faut pas faire

Non.
system renvoit un code retour (dans d0.w) égal au code retour que le programme a renvoyé au système lors de son arrêt (via exit ou le rts de main).
C'est lui qui t'indique s'il y a une erreur.

Rien n'empèche de le rediriger vers le link par exemple.

(OT: sous AMS, ROM_CALL_479 est un printf sur le link, à condition que ROM_CALL_47A "RedirFlag" vaille 1. Ca pourrait être pas mal que PedroM exporte également ceci.)

Super, merci pour les infos, c'est plus clair !
Quand je parlais de "définir moi-même" stdin et stderr, je parlais de définitions pour expliquer ce que c'est, ce que tu as très bien fait. (même si je crois qu'un FILE est un HSYM, mais toute façon je m'en fous).

Au fait, par défaut, ce que j'envoie à stdout et et stderr arrive à l'écran ? A moi après de faire le sprintf( sortie_désirée, truc ) pour que ça puisse être récupéré par > ou 2> c'est ça ? (ou directement printf( truc ) si ce n'est pas une erreur)

Folco (./11) :
Au fait, par défaut, ce que j'envoie à stdout et et stderr arrive à l'écran ?

Oui.

Folco (./11) :
A moi après de faire le sprintf( sortie_désirée, truc ) pour que ça puisse être récupéré par > ou 2> c'est ça ?

stdout est récupéré par >
stderr est récupéré par 2>

Lionel Debroux (./10) :
(OT: sous AMS, ROM_CALL_479 est un printf sur le link, à condition que ROM_CALL_47A "RedirFlag" vaille 1. Ca pourrait être pas mal que PedroM exporte également ceci.)

Désormais je n'ajouterai que mes interfaces proprios incompatibles avec AMS
(Nan, en fait, c'est juste que je rajouterai "/dev/tty" en plus de "/dev/null" comme "nom de fichier spécial").

Ah ben tiens, j'avais lu un truc à propos de /dev/null dans files.c, et je voulais te demander si on peut l'utiliser dans un programme
Par exemple, un programme lancé avec -q, j'aimerais rediriger stdout vers /dev/null, que dois-je écrire ?

Merci pour le reste, j'ai enfin compris \o/

Folco (./13) :
Ah ben tiens, j'avais lu un truc à propos de /dev/null dans files.c, et je voulais te demander si on peut l'utiliser dans un programme

Oui

Folco (./13) :
Par exemple, un programme lancé avec -q, j'aimerais rediriger stdout vers /dev/null, que dois-je écrire ?

system ("eexec -q > /dev/null");

Et si je veux faire ça dans mon programme, il est lancé, il se rend compte qu'on lui a passé '-q', donc le fait de faire une redirection de stdout vers /dev/null est beaucoup plus simple que d'aller, à chaque fois, tester le bit kivabien pour savoir s'il doit écrire quelque chose à l'écran.
J'utilise pas system(echo(truc)) dans mes programmes, mais directement printf (et maintenant, fprintf )

En fait, je veux faire un:
if( option == "-q" )
then redirect( stdout , /dev/null )
endif

Comme ça, je continue à "afficher" tout ce que je veux sans plus rien tester.

freopen (stdout, "/dev/null", "w");
peut être alors ?

Sûrement ça, j'essaye demain \o/

Habituellement, est-ce que seules les erreurs fatales sont renvoyées vers stderr ? Exemple, si je lis un fichier de config, et qu'il et invalide, le comportement codé est de l'ignorer et d'utiliser la configuration par défaut. L'erreur signalée est donc non fatale, doit-elle être alors imprimée sur stdout, ou malgré tout vers stderr ?

Honnétement, tu fais ce que tu veux.
D'habitude, les warnings sont aussi envoyés sur stderr, mais bon.

Folco (./18) :
Habituellement, est-ce que seules les erreurs fatales sont renvoyées vers stderr ? Exemple, si je lis un fichier de config, et qu'il et invalide, le comportement codé est de l'ignorer et d'utiliser la configuration par défaut. L'erreur signalée est donc non fatale, doit-elle être alors imprimée sur stdout, ou malgré tout vers stderr ?

A toi de voir quel est ce qui t'interesse le plus. L'intérêt principal du flux d'erreur est surtout de ne pas avoir de message d'erreur/avertissement parasites qui se mélange au résultat retourné.
La sortie standard peux ainsi être réutilisée dans un pipe par exemple.

Ok, merci.

Pendant que j'y pense, l'écran est donc un fichier aussi ? Il utilise un callback pour dessiner/scroller etc... ? C'est pas à ça que sert vcbprintf ?

On peut voir ca comme ca oui.
oui.
oui.