Stato di uscita non zero per uscita pulita

Dipende dall'ambiente, ma direi che è di cattivo gusto.

I sistemi di tipo Unix hanno una strong convenzione che uno stato di uscita di 0 denota successo, e qualsiasi stato di uscita diverso da zero indica un errore. Alcuni, ma non tutti, programmi distinguono tra diversi tipi di guasti con codici di uscita diversi da zero; ad esempio grep restituisce in genere 0 se il modello è stato trovato, 1 se non lo era, e 2 (o più) se c'è stato un errore come un file mancante.

Questa convenzione è praticamente collegata alle shell Unix. Ad esempio, in sh , bash e altre shell Bourne-like, l'istruzione if considera uno stato di uscita 0 come successo / true e uno stato di uscita diverso da zero come errore / falso:

if your-command
then
    echo ok
else
    echo FAILURE
fi

Credo che le convenzioni di MS Windows siano simili.

Ora non c'è sicuramente nulla che ti impedisca di scrivere il tuo programma che usa codici di uscita non convenzionali, specialmente se non c'è altro che possa interagire con esso, ma tieni presente che stai violando una convenzione ben stabilita e che potrebbe torna indietro e morde dopo.

Il modo usuale per un programma di restituire questo tipo di informazioni è di stamparlo su stdout :

status = $(your-command)
echo Result is $status

Dipende da ciò che il tuo ambiente si aspetta.

Il mio preferito per wierdness, da Wikipedia :

In OpenVMS, success is indicated by odd values and failure by even values. The value is a 32 bit integer with sub-fields: control bits, facility number, message number and severity. Severity values are divided between success (Success, Informational) and failure (Warning, Error, Fatal).

Penso che ci sia un precedente se il codice di uscita restituisce informazioni rilevanti significative al chiamante e la definizione di successo non è veramente binaria. Il precedente a cui sto pensando è robocopy che restituisce una sfilza di cose diverse a seconda di cosa è successo .

Aggiungerò che a causa di questo finiamo sempre con il debugging - la maggior parte dell'utilità assume il codice di uscita 0 == success, quindi andiamo fuori di testa quando robocopy restituisce 1 perché copiava roba diversa da zero perché non copiava cose ma non ha avuto neanche un errore.

non restituire 0 per una corsa corretta è una cattiva idea, perché può creare confusione per chi esegue il programma. Che cosa succede se alcuni hanno eseguito il tuo programma più di 100 volte con input diversi e volevi sapere quanti falliti o completati con successo, con un singolo valore di successo rende molto più facile individuare le differenze rispetto a molti valori diversi.

Se hai un programma che ha più percorsi di ritorno riusciti che possono tutti significare cose diverse, direi che è un segno che il tuo programma è mal progettato.

So di un caso che ritengo sia accettabile. Conosco un framework di test che esce con il numero totale di fallimenti del test. Ad esempio, se il test runner completa senza test falliti, esce con zero. Se un test fallisce, anche se il test runner stesso funziona in modo efficace, esce con uno 1. Se falliscono due restituisce 2, ecc. Questo sale fino a 250, che significa "250 o più fallimenti di test".

Utilizza i codici di uscita > 250 per indicare uscite anomale.

Mentre questo viola la convenzione, funziona in pratica.

Dipende davvero da cosa stai cercando di comunicare con il codice. DB2, ad esempio, restituisce 100 se non sono stati trovati dati, vari altri valori positivi per gli avvisi e valori negativi per gli errori. Oracle fa qualcosa di simile.

Quindi, se ci sono diversi stati di successo, potrebbe valere la pena di utilizzare diversi valori di ritorno.

Un buon esempio: man sa-update (spamassassin)

CODICI DI USCITA

• Un codice di uscita di 0 indica che era disponibile un aggiornamento e che è stato scaricato e installato correttamente se non è stato specificato --checkonly.
• Un codice di uscita di 1 indica che non erano disponibili nuovi aggiornamenti.
• Un codice di uscita di 2 significa ...

In questo caso, l'uscita 1 è semplicemente un codice informativo. Tuttavia, se avessi scritto il codice, non avrei scelto 1 dal solito errore di rete.