Ir a Técnicas de manejo de errores [cerrado]

Recién estoy comenzando con Go. Mi código está empezando a tener mucho de esto:

   if err != nil {
      //handle err
   }

o esto

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

¿Existen algunos buenos modismos / estrategias / mejores prácticas para verificar y manejar errores en Go?

EDITAR para aclarar: no estoy regañando ni sugiriendo que el equipo de Go proponga algo mejor. Estoy preguntando si lo estoy haciendo bien o si me perdí alguna técnica que se le ocurrió a la comunidad. Gracias a todos.

Su código es idiomático y, en mi opinión, es la mejor práctica disponible. Algunos estarían en desacuerdo con seguridad, pero yo diría que este es el estilo que se ve en todas las bibliotecas estándar de Golang . En otras palabras, los autores de Go escriben el manejo de errores de esta manera.

Seis meses después de que se hiciera esta pregunta, Rob Pike escribió una publicación de blog titulada Los errores son valores .

Allí argumenta que no es necesario programar de la forma presentada por el OP, y menciona varios lugares en la biblioteca estándar donde usan un patrón diferente.

Por supuesto, una declaración común que involucra un valor de error es probar si es nulo, pero hay muchas otras cosas que se pueden hacer con un valor de error, y la aplicación de algunas de esas otras cosas puede mejorar su programa, eliminando gran parte del texto estándar que surge si cada error se verifica con una instrucción if de memoria.

...

Utilice el lenguaje para simplificar su manejo de errores.

Pero recuerde: hagas lo que hagas, ¡siempre revisa tus errores!

Es una buena lectura.

Estoy de acuerdo con la respuesta de jnml de que ambos son códigos idiomáticos y agrego lo siguiente:

Tu primer ejemplo:

if err != nil {
      //handle err
}

es más idiomático cuando se trata de más de un valor de retorno. por ejemplo:

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

Su segundo ejemplo es una buena taquigrafía cuando solo se ocupa del errvalor. Esto se aplica si la función solo devuelve un error, o si ignora deliberadamente los valores devueltos que no sean error. Como ejemplo, esto a veces se usa con las funciones Readery Writerque devuelven un intdel número de bytes escritos (a veces información innecesaria) y un error:

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

La segunda forma se denomina uso de una instrucción de inicialización if .

Entonces, en lo que respecta a las mejores prácticas, hasta donde yo sé (excepto por el uso del paquete "errors" para crear nuevos errores cuando los necesite), ha cubierto prácticamente todo lo que necesita saber sobre los errores en Go!

EDIT: Si descubre que realmente no puede vivir sin excepciones, se puede imitar con defer, panicyrecover .

Hice una biblioteca para simplificar el manejo de errores y la canalización a través de una cola de funciones de Go.

Puede encontrarlo aquí: https://github.com/go-on/queue

Tiene una variante sintáctica compacta y verbosa. A continuación, se muestra un ejemplo de la sintaxis corta:

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:
           ...
       }
    }
}

Tenga en cuenta que hay un poco de sobrecarga de rendimiento, ya que hace uso de la reflexión.

Además, este no es un código go idiomático, por lo que querrá usarlo en sus propios proyectos, o si su equipo está de acuerdo en usarlo.

Una "estrategia" para manejar errores en golang y en otros lenguajes es propagar continuamente errores en la pila de llamadas hasta que esté lo suficientemente alto en la pila de llamadas para manejar ese error. Si intentó manejar ese error demasiado pronto, es probable que termine repitiendo el código. Si lo maneja demasiado tarde, romperá algo en su código. Golang hace que este proceso sea muy fácil, ya que deja muy claro si está manejando un error en una ubicación determinada o propagándolo.

Si va a ignorar el error, un simple _ revelará este hecho con mucha claridad. Si lo está manejando, entonces exactamente qué caso del error está manejando es claro, ya que lo verificará en la declaración if.

Como la gente dijo anteriormente, un error es en realidad solo un valor normal. Esto lo trata como tal.

Los dioses Go han publicado un "borrador de diseño" para el manejo de errores en Go 2. Su objetivo es cambiar el idioma de los errores:

Resumen y diseño

¡Quieren comentarios de los usuarios!

Wiki de comentarios

Brevemente, se ve así:

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

ACTUALIZACIÓN: El diseño preliminar ha recibido muchas críticas, por lo que redacté los Requisitos a considerar para el manejo de errores de Go 2 con un menú de posibilidades para una solución eventual.

La mayoría en la industria siguen las reglas estándar mencionadas en la documentación de golang Manejo de errores y Go . Y también ayuda a la generación de documentos para proyectos.

A continuación se muestra mi opinión sobre la reducción del manejo de errores en Go, el ejemplo es para cuando se obtienen parámetros de URL HTTP:

(Patrón de diseño derivado de 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
}

llamarlo para múltiples parámetros posibles sería el siguiente:

    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
    }

Esta no es una solución milagrosa, la desventaja es que si tuvo varios errores, solo puede obtener el último error.

Pero en este caso es relativamente repetitivo y de bajo riesgo, por lo tanto, puedo obtener el último error posible.

Tu puedes limpiar su código de manejo de errores para errores similares (ya que los errores son valores que hay que tener cuidado aquí) y escribe una función que se llama con el error en el pasado para controlar el error. No tendrá que escribir "if err! = Nil {}" cada vez que lo haga. Nuevamente, esto solo resultará en la limpieza del código, pero no creo que sea la forma idiomática de hacer las cosas.

Una vez más, solo porque puedas no significa que debas hacerlo .

goerr permite manejar errores con funciones

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)
}

Si desea un control preciso de los errores, esta puede no ser la solución, pero para mí, la mayoría de las veces, cualquier error es un obstáculo.

Entonces, uso funciones en su lugar.

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

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