Nel caso in cui un pacchetto Go utilizzi log.Fatal e quando?

Question

Ho finora evitato l'uso di log.Fatal, ma recentemente ho scoperto casualmente queste domande; code-coverage e tests-using-log-fatal.

Uno dei commenti delle domande di copertura 100 del codice dice:

... Nella stragrande maggioranza dei casi log.Fatal dovrebbe essere essere utilizzato solo nelle funzioni principali, o init (o, eventualmente, alcune cose destinata a essere chiamato solo direttamente da loro)"

andare fatto pensare, così ho cominciato a guardare il codice della libreria standard fornito con Go. ci sono un sacco di esempi in cui il codice prova nella biblioteca fa uso di log.Fatal che sembra soddisfacente alcuni esempi al di fuori del codice di test, come ad esempio in net/http, di seguito riportate:

// net/http/transport.go 
func (t *Transport) putIdleConn(pconn *persistConn) bool { 
    ... 
    for _, exist := range t.idleConn[key] { 
     if exist == pconn { 
      log.Fatalf("dup idle pconn %p in freelist", pconn) 
     } 
    } 
    ... 
} 

Se la sua è delle migliori pratiche per evitare l'uso di log.Fatal, perché è utilizzato a tutti nelle librerie standard, mi sarei aspettato basta restituire un errore. Sembra ingiusto che l'utente della libreria faccia chiamare os.Exit e non fornisca alcuna possibilità per l'applicazione di ripulire.

posso essere ingenuo, così da qui la mia domanda come una pratica migliore sembrerebbe quella di chiamare log.Panic che può essere recuperata e la mia teorica lungo in esecuzione un'applicazione stabile potrebbe avere la possibilità di salire dalle ceneri.

Quindi cosa sarebbe meglio dire per Go in merito a quando dovrebbe log.Fatal dovrebbe essere utilizzato?

Answer 1

Potrebbe essere solo io, ma ecco come uso log.Fatal. Secondo le convenzioni UNIX, un processo che rileva un errore dovrebbe fallire il prima possibile con un codice di uscita diverso da zero. Questo mi ha portato alle seguenti linee guida da utilizzare quando log.Fatal ...

1. ... si verifica un errore in uno dei miei func init(), in quanto questi si verificano quando le importazioni sono trattati o prima della func principale si chiama, rispettivamente. Viceversa, faccio solo cose che non influiscono direttamente sull'unità di lavoro che la biblioteca o il cmd dovrebbero fare. Ad esempio, ho impostato la registrazione e controllo se abbiamo un ambiente sano e parametri. Non è necessario eseguire main se abbiamo bandiere non valide, giusto? E se non possiamo dare un feedback adeguato, dovremmo dirlo presto.
2. ... succede un errore di cui so che è irrecuperabile. Supponiamo di avere un programma che crea una miniatura di un file immagine dato sulla riga di comando. Se questo file non esiste o non è leggibile a causa di autorizzazioni insufficienti, non vi è alcun motivo per continuare e questo errore non può essere ripristinato da. Quindi aderiamo alle convenzioni e falliamo.
3. ... si verifica un errore durante un processo che potrebbe non essere reversibile. Questa è una specie di definizione morbida, lo so. Lascia che ti illustri. Supponiamo di avere un'implementazione di cp e che sia stata avviata per essere non interattiva e copiare ricorsivamente una directory. Ora, assumiamo che incontriamo un file nella directory di destinazione che ha lo stesso nome (ma contenuto diverso) come file da copiare lì. Dal momento che non possiamo chiedere all'utente di decidere cosa fare e non possiamo copiare questo file, abbiamo un problema. Poiché l'utente supporrà che le directory di origine e di destinazione siano copie esatte quando finiamo con codice di uscita zero, non possiamo semplicemente saltare il file in questione. Tuttavia, non possiamo semplicemente sovrascriverlo, poiché questo potrebbe potenzialmente distruggere le informazioni.Questa è una situazione che non possiamo recuperare da una richiesta esplicita da parte dell'utente, quindi userei lo log.Fatal per spiegare la situazione, obbedendo al principio di fallire il prima possibile.