La convalida dei parametri di funzione utilizza errori in un modello corretto in Go?

Question

La convalida dei parametri utilizzando i codici di errore è considerata una buona pratica? Intendo dove qualcuno dovrebbe usare gli errori contro il panico (ci sono delle linee guida?).

Per esempio:

• sta controllando per i non-nil + restituendo un errore se è pari a zero un buon pratica?
• o il controllo per il corretto intero varia ecc

immagino che l'uso di errori che spesso farebbero Go sento molto C-ish e starebbe piuttosto male. I panici sono una buona alternativa in quelle situazioni?

Oppure un Gopher dovrebbe utilizzare l'approccio Python/Ruby/JS "lasciare che fallisca"?

Sono un po 'confuso perché il panico è per veri "errori" nella mia comprensione. Ma usando sempre gli errori è solo cattivo.

E anche se dovessi restituire il codice di errore: cosa potrei fare se qualcuno passa il parametro sbagliato alla mia funzione ma ignora i codici di errore? -> Niente! Quindi, onestamente, direi che il panico è piacevole per quelle situazioni, ma in un linguaggio in cui i codici di errore sono usati oltre il panico, questo non è molto chiaro.

Answer 1

"Escaping" panic s in Go (voglio dire, quelli che potrebbero essere prodotte dalle funzioni che compongono l'API pubblica del vostro pacchetto) sono a che fare con gli errori programmatori DO. Quindi, se la tua funzione ottiene un puntatore a un oggetto e non può essere nil (per esempio, per indicare che il valore è mancante) vai avanti e dereferenzia il puntatore per rendere il runtime panic stesso se risulta essere nil. Se una funzione prevede un numero intero che deve essere compreso in un determinato intervallo, panic se non è compreso nell'intervallo — perché in un programma corretto, tutti i valori che potrebbero essere passati alla funzione sono in tale intervallo e se non lo fanno Quindi il programmatore non ha rispettato l'API o non ha disinfettato il valore acquisito dall'esterno che, ancora una volta, non è colpa sua.

D'altra parte, i problemi come l'insufficienza di aprire un file o pefrorm qualche altra azione si suppone la funzione da eseguire quando viene chiamato correttamente dovrebbe non causa panic s e la funzione dovrebbe restituire un errore appropriato, invece.

Si noti che la raccomandazione per il controllo esplicito dei parametri null nelle funzioni delle API pubbliche in codice .NET e Java ha l'obiettivo diverso di rendere tali tipi di errori più leggibili. Ma dal momento che il 99% del codice .NET e Java fa semplicemente propagare tutte le eccezioni al livello superiore (e quindi essere visualizzate o possono essere registrate), sostituisce solo un'eccezione (generata da runtime) con un'altra. Potrebbe rendere più ovvio l'errore — l'esecuzione non riesce nella funzione API, non da qualche parte più in basso nello stack di chiamate — ma aggiunge cruft non necessario a queste funzioni API. Quindi sì, questo è supponente ma la mia opinione soggettiva è: lasciarlo solo andare in crash è OK in Go — otterrai una traccia di stack descrittiva.

TL; DR

In relazione al trattamento di problemi run-time,

• panic s sono per errori di programmazione;
• errori di ritorno è per problemi con lo svolgimento dei compiti previsti delle funzioni.

---

Un altro uso legittimo panic s è rapida "freddo-path" ritorno dalla profonda trasformazione ricorsiva/calcolo; in questo caso, il pacchetto deve ricevere e elaborare il valore panic e le corrispondenti funzioni API pubbliche devono restituire errori. Vedi this e this per maggiori informazioni.

Answer 2

La risposta a questo è soggettiva. Qui sono i miei pensieri:

Per quanto riguarda il panico, mi piace questa citazione da Go By Example (ref)

Un panico in genere significa qualcosa è andato storto in modo imprevisto. Principalmente lo usiamo per fallire velocemente sugli errori che non dovrebbero verificarsi durante il normale funzionamento, o che non siamo preparati a gestire con garbo.

Nella descrizione del caso d'uso, direi che dovresti generare errori e gestire gli errori. Vorrei inoltre sostenere che è una buona pratica controllare lo stato di errore quando uno è fornito dalla funzione che si sta utilizzando e che l'utente dovrebbe controllare se ne viene fornito uno nella documentazione.

Panico Utilizzerò per interrompere l'esecuzione se corro un errore che viene restituito dalla funzione che si sta scrivendo che controllo e non ho modo di recuperare.