Devo indicare il nome del programma quando si verifica un avviso o un errore?


13

Se sto scrivendo uno script o un programma, dovrei inviare a stderr il suo nome insieme a un messaggio di avviso o di errore? Per esempio:

./script.sh: Warning! Variable "var" lowered down to 10.

o:

./prog.py: Error! No such file: "file.cfg".

Capisco che generalmente è solo una questione di gusti (soprattutto se scrivi le tue cose per te), ma mi chiedo se c'è qualcosa di convenzionale in questo? Credo che la maggior parte delle utility UNIX / Linux scrivano i loro nomi quando succede qualcosa, quindi sembra essere una buona cosa, ma ci sono linee guida o regole non dette su come farlo e come non farlo?

Ad esempio, non è consigliabile installare i binari sotto /usr/bin/, piuttosto sotto /usr/local/bin/o qualcos'altro. Ci sono regole simili sull'output di stderr? Dovrei scrivere il nome seguito da due punti? O semplicemente "Attenzione!" e "Errore!" parole? Non sono riuscito a trovare nulla, ma forse qualcuno potrebbe indicarmi dove leggerlo.

Questa domanda riguarda un po 'le pratiche di programmazione, ma ho pensato che fosse più appropriato qui piuttosto che su StackOverflow , poiché riguarda le tradizioni UNIX / Linux e non la programmazione in generale.


5
Il nome del programma può aiutare il debug di un casuale no such fileda chissà quale programma in una foo | bar | bazpipeline.
thrig

@thrig Grazie, buon punto. Il mio non dovrebbe essere convogliato, ma chi lo sa. Immagino sia meglio attenersi al comportamento standard.
gsarret,

Risposte:


16

È pratica comune salvare l' argomento 0 passato a un programma C maine usarlo come parametro per perror- per programmi semplici:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
    char *foo = malloc(9999999999L);
    if (foo == 0)
        perror(argv[0]);
    return 0;
}

chiama quel programma "pippo", ed eseguendolo illustra il punto:

> ./foo
./foo: Cannot allocate memory

I programmi complicati possono essere aggiunti al testo (o utilizzare solo il nome file senza il percorso), ma mantenendo il nome del programma è possibile trovare da dove proviene un programma che si comporta male.

Non esiste uno schema universalmente accettato per i messaggi di errore, ma alcuni programmi ampiamente utilizzati (come gcc) aggiungono una categoria di messaggi come "Errore" o "Avviso". Ecco un esempio da uno dei miei log di build:

compiling fld_def (obj_s)
../form/fld_def.c: In function '_nc_Copy_Argument':
../form/fld_def.c:164:14: warning: cast discards 'const' qualifier from pointer target type [-Wcast-qual]
        res = (TypeArgument *)argp;
              ^

In questo esempio, gcc separa i campi con due punti e aggiunge una categoria "avviso" dopo il nome file, il numero di riga, il numero di colonna e prima del messaggio effettivo. Ma ci sono diverse varianti, il che rende complicato per i programmi (come vi-like-emacs ) analizzare le informazioni.

Per i compilatori, l'utilizzo di una categoria nel messaggio semplifica il rilevamento degli errori fatali (che potrebbero non essere immediatamente fatali ) e degli avvisi. Se il tuo programma esce per un errore, non si aggiunge molto per dire che alcuni sono davvero avvisi e altri sono errori. Ma quando si comporta diversamente (o continua a funzionare più o meno) la categoria aiuta a diagnosticare il problema riscontrato.


Grazie per un esempio, ho capito. Che dire di "Errore" e "Avviso", ingombrano l'output?
gsarret,

La tua ultima modifica - esattamente quello a cui stavo pensando! A che serve se esce subito dopo il messaggio err? Grazie ancora.
gsarret,

8

Se un programma viene invocato come parte di uno script in cui vengono richiamati molti altri programmi e se non stampa il suo nome, gli utenti troveranno difficile (er) capire da dove provenga l'errore.

(Se l'errore è una condizione interna imprevista che potrebbe richiedere il debug, si desidera ancora più informazioni: non solo il nome del programma, ma un file di origine e il numero di riga e possibilmente un backtrace.)


Grazie. Di solito scrivo programmi per me stesso (simulazione numerica) quindi c'è un solo utente, tuttavia potrei condividerli un giorno. Inoltre non sono così complessi (beh, almeno ancora), quindi non c'è problema a trovare la fonte dell'errore, ma grazie per il suggerimento, potrebbe essere utile in futuro.
gsarret,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.