Go Error Handling Techniques [closed]

Ho appena iniziato con Go. Il mio codice sta iniziando ad avere molto di questo:

   if err != nil {
      //handle err
   }

o questo

  if err := rows.Scan(&some_column); err != nil {
      //handle err
  }

Ci sono alcuni buoni idiomi / strategie / best practice per il controllo e la gestione degli errori in Go?

MODIFICA per chiarire: non sto mal di pancia o suggerisco che il team di Go escogiti qualcosa di meglio. Chiedo se lo sto facendo bene o ho perso qualche tecnica che la comunità ha escogitato. Ringrazia tutti.

Il tuo codice è idiomatico e secondo me è la migliore pratica disponibile. Alcuni sarebbero sicuramente in disaccordo, ma direi che questo è lo stile visto in tutte le librerie standard di Golang . In altre parole, gli autori di Go scrivono la gestione degli errori in questo modo.

Sei mesi dopo questa domanda, Rob Pike ha scritto un post sul blog intitolato Gli errori sono valori .

Lì afferma che non è necessario programmare nel modo presentato dall'OP e menziona diversi punti nella libreria standard in cui usano un modello diverso.

Ovviamente un'affermazione comune che coinvolge un valore di errore è verificare se è nullo, ma ci sono innumerevoli altre cose che si possono fare con un valore di errore e l'applicazione di alcune di queste altre cose può migliorare il tuo programma, eliminando gran parte del boilerplate che si verifica se ogni errore viene controllato con un'istruzione if meccanica.

...

Usa la lingua per semplificare la gestione degli errori.

Ma ricorda: qualunque cosa tu faccia, controlla sempre i tuoi errori!

È una buona lettura.

Sono d'accordo con la risposta di jnml che sono entrambi codici idiomatici e aggiungerei quanto segue:

Il tuo primo esempio:

if err != nil {
      //handle err
}

è più idiomatico quando si tratta di più di un valore di ritorno. per esempio:

val, err := someFunc()
if err != nil {
      //handle err
}
//do stuff with val

Il tuo secondo esempio è una bella scorciatoia quando hai a che fare solo con il errvalore. Ciò si applica se la funzione restituisce solo un error, o se si ignorano deliberatamente i valori restituiti diversi da error. Ad esempio, a volte viene utilizzato con le funzioni Readere Writerche restituiscono un intnumero di byte scritti (a volte informazioni non necessarie) e un error:

if _, err := f.Read(file); err != nil {
      //handle err
}
//do stuff with f

La seconda forma viene definita utilizzando un'istruzione di inizializzazione if .

Quindi, per quanto riguarda le migliori pratiche, per quanto ne so (eccetto per l'utilizzo del pacchetto "errors" per creare nuovi errori quando ne avete bisogno) avete coperto praticamente tutto ciò che dovete sapere sugli errori in Go!

EDIT: Se scopri che davvero non puoi vivere senza eccezioni, puoi imitarle con defer, panic&recover .

Ho creato una libreria per la gestione degli errori semplificata e il piping attraverso una coda di funzioni Go.

Puoi trovarlo qui: https://github.com/go-on/queue

Ha una variante sintattica compatta e una verbosa. Ecco un esempio per la sintassi breve:

import "github.com/go-on/queue/q"

func SaveUser(w http.ResponseWriter, rq *http.Request) {
    u := &User{}
    err := q.Q(                      
        ioutil.ReadAll, rq.Body,  // read json (returns json and error)
    )(
        // q.V pipes the json from the previous function call
        json.Unmarshal, q.V, u,   // unmarshal json from above  (returns error)
    )(
        u.Validate,               // validate the user (returns error)
    )(
        u.Save,                   // save the user (returns error)
    )(
        ok, w,                    // send the "ok" message (returns no error)
    ).Run()

    if err != nil {
       switch err {
         case *json.SyntaxError:
           ...
       }
    }
}

Si prega di essere consapevoli del fatto che c'è un piccolo sovraccarico sulle prestazioni, poiché utilizza la riflessione.

Inoltre questo non è un codice go idiomatico, quindi vorrai usarlo nei tuoi progetti o se il tuo team è d'accordo nell'usarlo.

Una "strategia" per la gestione degli errori in golang e in altri linguaggi consiste nel propagare continuamente gli errori nello stack di chiamate fino a quando non si è abbastanza in alto nello stack di chiamate da gestire quell'errore. Se hai provato a gestire l'errore troppo presto, probabilmente finirai per ripetere il codice. Se lo gestisci troppo tardi, romperai qualcosa nel tuo codice. Golang rende questo processo estremamente semplice in quanto rende estremamente chiaro se stai gestendo un errore in una data posizione o se lo stai propagando.

Se ignorerai l'errore, un semplice _ rivelerà questo fatto molto chiaramente. Se lo stai gestendo, allora esattamente quale caso dell'errore stai gestendo è chiaro poiché lo controllerai nell'istruzione if.

Come le persone hanno detto sopra, un errore è in realtà solo un valore normale. Questo lo tratta come tale.

Gli dei di Go hanno pubblicato una "bozza di progetto" per la gestione degli errori in Go 2. Ha lo scopo di cambiare l'idioma degli errori:

Panoramica e design

Vogliono feedback dagli utenti!

Wiki di feedback

In breve, sembra che:

func f() error {
   handle err { fmt.Println(err); return err }
   check mayFail()
   check canFail()
}

AGGIORNAMENTO: La bozza del progetto ha ricevuto molte critiche, quindi ho redatto i requisiti da considerare per la gestione degli errori di Go 2 con un menu di possibilità per un'eventuale soluzione.

La maggior parte del settore segue le regole standard menzionate nella documentazione Golang Gestione degli errori e Go . E aiuta anche la generazione di documenti per il progetto.

Di seguito è riportato il mio parere sulla riduzione della gestione degli errori per Go, l'esempio è per quando si ottengono i parametri URL HTTP:

(Modello di progettazione derivato da https://blog.golang.org/errors-are-values )

type HTTPAdapter struct {
    Error *common.AppError
}

func (adapter *HTTPAdapter) ReadUUID(r *http.Request, param string, possibleError int) uuid.UUID {
    requestUUID := uuid.Parse(mux.Vars(r)[param])
    if requestUUID == nil { 
        adapter.Error = common.NewAppError(fmt.Errorf("parameter %v is not valid", param),
            possibleError, http.StatusBadRequest)
    }
    return requestUUID
}

chiamandolo per più parametri possibili sarebbe il seguente:

    adapter := &httphelper.HTTPAdapter{}
    viewingID := adapter.ReadUUID(r, "viewingID", common.ErrorWhenReadingViewingID)
    messageID := adapter.ReadUUID(r, "messageID", common.ErrorWhenReadingMessadeID)
    if adapter.Error != nil {
        return nil, adapter.Error
    }

Questo non è un proiettile d'argento, lo svantaggio è che se hai più errori puoi ottenere solo l'ultimo errore.

Ma in questo caso è relativamente ripetitivo e a basso rischio, quindi posso solo ottenere l'ultimo errore possibile.

È possibile ripulire il codice di gestione degli errori per gli errori simili (dal momento che gli errori sono valori che bisogna stare attenti qui) e scrivere una funzione che si chiama con l'errore passata per gestire l'errore. Allora non dovrai scrivere "if err! = Nil {}" ogni volta. Di nuovo, questo risulterà solo nella pulizia del codice, ma non penso che sia il modo idiomatico di fare le cose.

Anche in questo caso, solo perché si può non significa che si dovrebbe .

goerr permette di gestire gli errori con le funzioni

package main

import "github.com/goerr/goerr"
import "fmt"

func ok(err error) {
    if err != nil {
        goerr.Return(err)
        // returns the error from do_somethingN() to main()
        // sequence() is terminated
    }
}

func sequence() error {
    ok(do_something1())
    ok(do_something2())
    ok(do_something3())

    return nil /// 1,2,3 succeeded
}
func do_something1() error { return nil }
func do_something2() error { return fmt.Errorf("2") }
func do_something3() error {
    fmt.Println("DOING 3")
    return nil
}

func main() {
    err_do_something := goerr.OR1(sequence)

    // handle errors

    fmt.Println(err_do_something)
}

Se vuoi un controllo preciso degli errori, questa potrebbe non essere la soluzione, ma per me, il più delle volte, qualsiasi errore è un ostacolo.

Quindi, uso invece le funzioni.

func Err(err error) {
    if err!=nil {
        fmt.Println("Oops", err)
        os.Exit(1)
    }
}

fi, err := os.Open("mmm.txt")
Err(err)