go - simple - Evite verificar si el error es cero repetición?

regresion lineal simple estadistica

Question

Actualmente estoy aprendiendo ir y parte de mi código se ve así:

a, err := doA()
if err != nil {
return nil, err
}
b, err := doB(a)
if err != nil {
return nil, err
}
c, err := doC(b)
if err != nil {
return nil, err
}
... and so on ...

Esto me parece un error porque la comprobación de errores ocupa la mayoría de las líneas. ¿Hay una mejor manera de manejar errores? ¿Puedo evitar esto con algunas refactorizaciones?

ACTUALIZACIÓN: Gracias por todas las respuestas. Tenga en cuenta que en mi ejemplo doB depende de a, doC depende de b y así sucesivamente. Por lo tanto, la mayoría de las refactorizaciones sugeridas no funcionan en este caso. ¿Alguna otra sugerencia?

Answer 1

Esta es una queja común, y hay varias respuestas a ella.

Estos son algunos de los más comunes:

1 - No es tan malo

Esta es una reacción muy común a estas quejas. El hecho de que tenga algunas líneas adicionales de código en su código no es realmente tan malo. Es solo un poco de mecanografía barata, y muy fácil de manejar cuando se lee.

2 - En realidad es algo bueno

Esto se basa en el hecho de que escribir y leer estas líneas adicionales es un muy buen recordatorio de que, de hecho, su lógica podría escapar en ese punto, y debe deshacer cualquier gestión de recursos que haya implementado en las líneas que lo preceden. Esto generalmente se plantea en comparación con las excepciones, que pueden interrumpir el flujo de la lógica de una manera implícita, lo que obliga al desarrollador a tener siempre en mente la ruta de error oculta. Hace algún tiempo escribí una queja más profunda sobre esto here .

3 - Utiliza el pánico / recupera

En algunas circunstancias específicas, puede evitar parte de ese trabajo al usar panic con un tipo conocido y luego usar recover justo antes de que su código de paquete salga al mundo, transformándolo en un error apropiado y devolviéndolo en su lugar. Esta técnica se ve más comúnmente para desenrollar lógica recursiva, como (un) Marshalers.

Personalmente, me esfuerzo por no abusar demasiado de esto, porque me relaciono más estrechamente con los puntos 1 y 2.

4 - Reorganizar el código un poco

En algunas circunstancias, puede reorganizar la lógica ligeramente para evitar la repetición.

Como un ejemplo trivial, esto:

err := doA()
if err != nil {
return err
}
err := doB()
if err != nil {
return err
}
return nil

también se puede organizar como:

err := doA()
if err != nil {
return err
}
return doB()

5 - Usa resultados nombrados

Algunas personas usan los resultados nombrados para quitar la variable err de la declaración de devolución. Sin embargo, recomendaría no hacerlo, ya que ahorra muy poco, reduce la claridad del código y hace que la lógica sea propensa a problemas sutiles cuando se definen uno o más resultados antes de la declaración de devolución del rescate.

6 - Use la declaración antes de la condición if

Como bien recordaba Tom Wilde en el siguiente comentario, if declaraciones en Go here antes de la condición. Entonces puedes hacer esto:

if err := doA(); err != nil {
return err
}

Esta es una buena expresión de Go, y se usa a menudo.

En algunos casos específicos, prefiero evitar incluir la declaración de esta manera solo para que sea independiente por motivos de claridad, pero esto es algo personal y sutil.

Answer 2

Podría usar parámetros de devolución nombrados para acortar un poco las cosas

Enlace de juegos

func doStuff() (result string, err error) {
a, err := doA()
if err != nil {
return
}
b, err := doB(a)
if err != nil {
return
}
result, err = doC(b)
if err != nil {
return
}
return
}

Después de que hayas programado en Go a while, apreciarás que tener que verificar el error para cada función te hace pensar en lo que realmente significa si la función funciona mal y cómo debes lidiar con ella.

Answer 3

Puede crear un tipo de contexto con valor de resultado y error.

type Type1 struct {
a int
b int
c int
err error
}
func (t *Type1) doA() {
if t.err != nil {
return
}
// do something
if err := do(); err != nil {
t.err = err
}
}
func (t *Type1) doB() {
if t.err != nil {
return
}
// do something
b, err := t.doWithA(a)
if err != nil {
t.err = err
return
}
t.b = b
}
func (t *Type1) doC() {
if t.err != nil {
return
}
// do something
c, err := do()
if err != nil {
t.err = err
return
}
t.c = c
}
func main() {
t := Type1{}
t.doA()
t.doB()
t.doC()
if t.err != nil {
// handle error in t
}
}

Answer 4

Puede pasar un error como argumento de función

func doA() (A, error) {
...
}
func doB(a A, err error) (B, error) {
...
}
c, err := doB(doA())

Me he dado cuenta de algunos métodos en el paquete "html / template" hacer esto, por ejemplo

func Must(t *Template, err error) *Template {
if err != nil {
panic(err)
}
return t
}

Answer 5

Si tiene muchas de esas situaciones recurrentes en las que tiene varias de estas comprobaciones de error, puede definir una función de utilidad como la siguiente:

func validError(errs ...error) error {
for i, _ := range errs {
if errs[i] != nil {
return errs[i]
}
}
return nil
}

Esto le permite seleccionar uno de los errores y devolver si hay alguno que no sea nulo.

Ejemplo de uso ( versión completa en el juego ):

x, err1 := doSomething(2)
y, err2 := doSomething(3)
if e := validError(err1, err2); e != nil {
return e
}

Por supuesto, esto solo se puede aplicar si las funciones no dependen entre sí, pero esta es una condición previa general para resumir el manejo de errores.

Answer 6

Te parece incorrecto, quizás porque estás acostumbrado a no manejar errores en el sitio de llamadas. Esto es bastante idiomático para ir, pero parece mucho repetitivo si no estás acostumbrado.

Sin embargo, tiene algunas ventajas.

1. debe pensar cuál es la forma correcta de manejar este error en el sitio donde se generó el error.
2. Es fácil leer el código para ver cada punto en el que el código abortará y regresará temprano.

Si realmente te molesta, puedes ser creativo con bucles y funciones anónimas, pero a menudo se vuelve complicado y difícil de leer.