Come si usa il codice di stato di uscita? [chiuso]

Il modo in cui i codici di stato di uscita vengono utilizzati dipende in gran parte dal tipo di applicazione. L'uso principale dei codici di stato di uscita è quando si desidera automatizzare l'esecuzione di applicazioni utilizzando lo scripting.

Se l'applicazione è un'applicazione interattiva, in cui l'aspettativa è che l'utente interagisca sempre direttamente con l'applicazione, i codici di stato di uscita vengono in gran parte ignorati. Non c'è mai una decisione (automatica) di fare cosa fare in seguito a seconda dell'uscita dall'applicazione.

Se l'applicazione è progettata per essere interattiva, ma ha anche una modalità 'batch' per l'esecuzione occasionale in uno script, l'applicazione di solito indica il successo o il fallimento, come un codice di stato booleano.

Se i progettisti dell'applicazione avevano davvero degli script in testa, allora probabilmente hanno aggiunto più codici di stato di uscita per diversi tipi di errore, in modo che gli autori di script possano reagire di conseguenza. Si tratta di errori a livello di utente e in genere vengono associati a una o più situazioni di errore interne.

Le eccezioni e i codici di stato di uscita sono due cose molto diverse. Le eccezioni sono allo scopo dell'applicazione; i codici di stato di uscita sono nell'ambito del sistema operativo.

Quando un'applicazione chiama un altro, in pratica, l'unico modo standard per determinare se il destinatario ha finito con successo è il codice di stato di uscita. 0 significa successo. Qualsiasi altra cosa significa fallimento. Il fatto che non esiste uno standard per il quale codice è quello che significa che determinare la fonte dell'errore spesso richiede di fare un ulteriore passaggio di consultazione della documentazione, quando disponibile. Data la grande varietà di problemi, la creazione di tale standard sarebbe praticamente impossibile da teorizzare: anche se è possibile standardizzare alcuni errori, come "file non trovato", un codice di uscita, ovvero un numero semplice, non sarà sufficientemente dettagliato : in caso di mancato rilevamento di un file, quale file era esattamente previsto?

Questo difetto è esattamente uguale a quello che ha spinto ad abbandonare i codici di errore entro un programma e usa invece le eccezioni.

Eccezioni:

• Sono spesso espliciti, in quanto contengono il tipo, il riepilogo e i dati aggiuntivi. Il tipo FileNotFoundException accoppiato con il percorso del file previsto e la traccia dello stack aiuta a identificare con precisione il problema, sia come utente di un programma che come programmatore, se è colpa del programma non riuscire a trovare il file o non essere in grado di ricorrere a un'altra opzione.

• Può essere catturato all'interno dell'applicazione stessa.

Quando si tratta di comunicazione tra processi, i servizi Web, ad esempio, consentono di emulare almeno il primo vantaggio delle eccezioni, fornendo la rappresentazione JSON / XML di un errore, piuttosto che un semplice codice di errore.

In un programma shell puoi usarli per prendere delle decisioni. In bash $? è la variabile che contiene lo stato dell'ultimo programma che è uscito.

if [$? -eq 0 ]; then
   echo "Everything is okay"
else
   echo "Something is terribly wrong!"
fi

I codici di uscita sono specifici del sistema operativo. In C99, <stdlib.h> conosce exit (3) e EXIT_SUCCESS & %codice%. Mi sto concentrando su Linux.

I sistemi POSIX e Linux accettano 256 valori diversi a EXIT_FAILURE , dove 0 è exit e altri valori diversi da zero (da 1 a 255) per alcuni tipi di errori.

BSD has attempted to standardize exit codes; see the file <sysexits.h>

^{Potresti avere diversi codici di uscita (ad esempio una dozzina di loro diversi). Non dimenticare di documentarli .}

Il waitpid (2) syscall può recuperare il codice di uscita di un bambino biforcuto processo e lo stato viene anche restituito da system (3)

Le eccezioni dovrebbero essere scoperte e gestite , almeno dal sistema di runtime (ad es. su C ++ o Java o Ocaml) .

Alcuni programmi registrano funzioni con atexit (3) e alcuni daemon o server stanno gestendo il segnale EXIT_SUCCESS (vedi signal (7) ), ecco perchè su Linux non è consigliabile kill (2) processi con SIGTERM (dovresti prova SIGKILL poi SIGTERM prima del% non commestibileSIGQUIT, per lasciare che un programma ben funzionante ripulisca il suo pasticcio prima della conclusione, ad esempio lascia che qualche gestore di database scarichi il suo stato su disco).

Usi i codici di uscita quando l'applicazione verrà eseguita da un processo separato, che può prendere decisioni in base ai risultati.

Quale codice di uscita dovresti restituire in determinate circostanze, sarà tra te e il tuo interlocutore. In genere utilizzo i codici di uscita per i lavori pianificati / attività e limito il ritorno al successo e al fallimento. Davvero tocca a te.