Estoy de acuerdo en que esta es la mejor manera de avanzar: solucionar el problema más común con un diseño simple.

No quiero hacer un cobertizo (siéntete libre de posponer esta conversación), pero Rust fue allí y finalmente se decidió por el operador de postfijo ? en lugar de una función integrada, para una mayor legibilidad.

La propuesta de gophercon cita ? en las ideas consideradas y da tres razones por las que se descartó: la primera ("las transferencias de flujo de control son, por regla general, acompañadas de palabras clave") y la tercera ("los controladores se definen de forma más natural con una palabra clave, por lo que los cheques también deberían) ya no se aplican. El segundo es estilístico: dice que, incluso si el operador postfijo funciona mejor para encadenar, aún puede leerse peor en algunos casos como:

check io.Copy(w, check newReader(foo))

en vez de:

io.Copy(w, newReader(foo)?)?

pero ahora tendríamos:

try(io.Copy(w, try(newReader(foo))))

que creo que es claramente el peor de los tres, ya que ni siquiera es obvio cuál es la función principal que se llama.

Entonces, la esencia de mi comentario es que las tres razones citadas en la propuesta de gophercon para no usar ? no se aplican a esta propuesta try ; ? es conciso, muy legible, no oscurece la estructura de la declaración (con su jerarquía de llamada de función interna) y se puede encadenar. Elimina aún más el desorden de la vista, sin oscurecer el flujo de control más de lo que ya lo hace el try() propuesto.

Para aclarar:

Lo hace

func f() (n int, err error) {
  n = 7
  try(errors.New("x"))
  // ...
}

devolver (0, "x") o (7, "x")? Yo asumiría lo último.

¿Se debe nombrar el retorno de error en el caso de que no haya decoración o manejo (como en una función auxiliar interna)? Supongo que no.

Su ejemplo devuelve 7, errors.New("x") . Esto debería quedar claro en el documento completo que se enviará pronto (https://golang.org/cl/180557).

No es necesario nombrar el parámetro de resultado de error para usar try . Solo necesita nombrarse si la función necesita hacer referencia a ella en una función diferida o en otro lugar.

Estoy realmente descontento con una _función_ incorporada que afecta el flujo de control de la persona que llama. Aprecio la imposibilidad de agregar nuevas palabras clave en Go 1, pero solucionar ese problema con funciones mágicas integradas me parece incorrecto. El sombreado de otras funciones integradas no tiene resultados tan impredecibles como el cambio de flujo de control.

No me gusta la apariencia de postfix ? , pero creo que aún supera a try() .

Editar: Bueno, logré olvidar por completo que el pánico existe y no es una palabra clave.

La propuesta detallada ya está aquí (en espera de mejoras de formato, próximamente) y se espera que responda muchas preguntas.

@dominikh La propuesta detallada analiza esto en detalle, pero tenga en cuenta que panic y recover son dos funciones integradas que también afectan el flujo de control.

Una aclaración/sugerencia de mejora:

if the last argument supplied to try, of type error, is not nil, the enclosing function’s error result variable (...) is set to that non-nil error value before the enclosing function returns

¿Podría esto decir is set to that non-nil error value and the enclosing function returns ? (s/antes/y)

En la primera lectura, before the enclosing function returns parecía que _eventualmente_ establecería el valor de error en algún momento en el futuro justo antes de que regresara la función, posiblemente en una línea posterior. La interpretación correcta es que try puede hacer que la función actual regrese. Ese es un comportamiento sorprendente para el lenguaje actual, por lo que un texto más claro sería bienvenido.

Creo que esto es solo azúcar, y un pequeño número de oponentes vocales se burlaron de golang sobre el uso repetido de escribir if err != nil ... y alguien se lo tomó en serio. No creo que sea un problema. Las únicas cosas que faltan son estos dos incorporados:

https://github.com/purpleidea/mgmt/blob/a235b760dc3047a0d66bb0b9d63c25bc746ed274/util/errwrap/errwrap.go#L26

No estoy seguro de por qué alguien escribiría una función como esta, pero cuál sería el resultado previsto para

try(foobar())

Si foobar devuelve (error, error)

Me retracto de mis preocupaciones anteriores sobre el flujo de control y ya no sugiero usar ? . Pido disculpas por la respuesta instintiva (aunque me gustaría señalar que esto no habría sucedido si el problema se hubiera presentado _después_ de que la propuesta completa estuviera disponible).

No estoy de acuerdo con la necesidad de un manejo de errores simplificado, pero estoy seguro de que es una batalla perdida. try como se establece en la propuesta parece ser la forma menos mala de hacerlo.

@webermaster Solo el último resultado error es especial para la expresión pasada a try , como se describe en el documento de la propuesta.

Al igual que @dominikh , tampoco estoy de acuerdo con la necesidad de un manejo de errores simplificado.

Mueve la complejidad vertical a la complejidad horizontal, lo que rara vez es una buena idea.

Sin embargo, si tuviera que elegir absolutamente entre simplificar las propuestas de manejo de errores, esta sería mi propuesta preferida.

Sería útil si esto pudiera ir acompañado (en alguna etapa de aceptación) por una herramienta para transformar el código Go para usar try en algún subconjunto de funciones que devuelven errores donde dicha transformación se puede realizar fácilmente sin cambiando la semántica. Se me ocurren tres beneficios:

• Al evaluar esta propuesta, permitiría a las personas tener una idea rápida de cómo se podría usar try en su base de código.
• Si try llega a una versión futura de Go, es probable que la gente quiera cambiar su código para usarlo. Tener una herramienta para automatizar los casos fáciles ayudará mucho.
• Tener una forma de transformar rápidamente una gran base de código para usar try facilitará el examen de los efectos de la implementación a escala. (La corrección, el rendimiento y el tamaño del código, por ejemplo). Sin embargo, la implementación puede ser lo suficientemente simple como para hacer que esto sea una consideración insignificante.

Solo me gustaría expresar que creo que un simple try(foo()) que realmente sale de la función de llamada nos quita la señal visual de que el flujo de la función puede cambiar según el resultado.

Siento que puedo trabajar con try si me acostumbro lo suficiente, pero también siento que necesitaremos soporte IDE adicional (o algo similar) para resaltar try para reconocer de manera eficiente el flujo implícito en las revisiones de código /sesiones de depuración

Lo que más me preocupa es la necesidad de tener valores de retorno con nombre solo para que la declaración diferida sea feliz.

Creo que el problema general de manejo de errores del que se queja la comunidad es una combinación del modelo de if err != nil Y agregar contexto a los errores. Las preguntas frecuentes establecen claramente que este último se omite intencionalmente como un problema separado, pero siento que esto se convierte en una solución incompleta, pero estaré dispuesto a darle una oportunidad después de pensar en estas 2 cosas:

1. Declare err al comienzo de la función.
   ¿Esto funciona? Recuerdo problemas con resultados diferidos y sin nombre. Si no es así, la propuesta debe considerar esto.

func sample() (string, error) {
  var err error
  defer fmt.HandleErrorf(&err, "whatever")
  s := try(f())
  return s, nil
}

1. Asigne valores como lo hicimos en el pasado, pero use una función auxiliar wrapf que tiene el modelo if err != nil .

func sample() (string, error) {
  s, err := f()
  try(wrapf(err, "whatever"))
  return s, nil
}
func wrapf(err error, format string, ...v interface{}) error {
  if err != nil {
    // err = wrapped error
  }
  return err
}

Si cualquiera funciona, puedo lidiar con eso.

func sample() (string, error) {
  var err error
  defer fmt.HandleErrorf(&err, "whatever")
  s := try(f())
  return s, nil
}

Esto no funcionará. El aplazamiento actualizará la variable local err , que no está relacionada con el valor devuelto.

func sample() (string, error) {
  s, err := f()
  try(wrapf(err, "whatever"))
  return s, nil
}
func wrapf(err error, format string, ...v interface{}) error {
  if err != nil {
    // err = wrapped error
  }
  return err
}

Eso debería funcionar. Sin embargo, llamará a wrapf incluso en un error nulo.
Esto también (continuará) funcionando, y en mi opinión es mucho más claro:

func sample() (string, error) {
  s, err := f()
  if err != nil {
      return "", wrap(err)
  }
  return s, nil
}

Nadie te obligará a usar try .

No estoy seguro de por qué alguien escribiría una función como esta, pero cuál sería el resultado previsto para

try(foobar())

Si foobar devuelve (error, error)

¿Por qué devolvería más de un error de una función? Si está devolviendo más de un error de la función, tal vez la función deba dividirse en dos en primer lugar, cada una devolviendo solo un error.

¿Podrías elaborar con un ejemplo?

@cespare : Debería ser posible que alguien escriba un go fix que reescriba el código existente adecuado para try modo que use try . Puede ser útil tener una idea de cómo se podría simplificar el código existente. No esperamos cambios significativos en el tamaño o el rendimiento del código, ya que try es solo azúcar sintáctico, reemplazando un patrón común por una pieza más corta de código fuente que produce esencialmente el mismo código de salida. Tenga en cuenta también que el código que usa try estará obligado a usar una versión de Go que sea al menos la versión en la que se introdujo try .

@lestrrat : Estuvo de acuerdo en que uno tendrá que aprender que try puede cambiar el flujo de control. Sospechamos que los IDE podrían resaltar eso con bastante facilidad.

@Goodwine : Como @ randall77 ya señaló, su primera sugerencia no funcionará. Una opción en la que hemos pensado (pero no discutida en el documento) es la posibilidad de tener alguna variable predeclarada que denote el resultado error (si está presente en primer lugar). Eso eliminaría la necesidad de nombrar ese resultado solo para que pueda usarse en defer . Pero eso sería aún más mágico; no parece justificado. El problema de nombrar el resultado de la devolución es esencialmente cosmético, y donde más importa es en las API generadas automáticamente atendidas por go doc y sus amigos. Sería fácil abordar esto en esas herramientas (consulte también las preguntas frecuentes del documento de diseño detallado sobre este tema).

@nictuku : con respecto a su sugerencia de aclaración (s/before/and/): creo que el código inmediatamente antes del párrafo al que se refiere deja en claro qué sucede exactamente, pero veo su punto, s/before/and/ may aclarar la prosa. Haré el cambio.

Ver CL 180637 .

La verdad es que me gusta mucho esta propuesta. Sin embargo, tengo una crítica. El punto de salida de las funciones en Go siempre ha estado marcado por return . Los pánicos también son puntos de salida, sin embargo, esos son errores catastróficos que normalmente no deben encontrarse nunca.

Hacer un punto de salida de una función que no es un return , y está destinado a ser un lugar común, puede conducir a un código mucho menos legible. Escuché sobre esto en una charla y es difícil no ver la belleza de cómo está estructurado este código:

func CopyFile(src, dst string) error {
    r, err := os.Open(src)
    if err != nil {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
    defer r.Close()

    w, err := os.Create(dst)
    if err != nil {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }

    if _, err := io.Copy(w, r); err != nil {
        w.Close()
        os.Remove(dst)
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }

    if err := w.Close(); err != nil {
        os.Remove(dst)
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
}

Este código puede parecer un gran lío, y fue _destinado_ por el borrador de manejo de errores, pero comparémoslo con lo mismo con try .

func CopyFile(src, dst string) error {
    defer func() {
        err = fmt.Errorf("copy %s %s: %v", src, dst, err)
    }()
    r, err := try(os.Open(src))
    defer r.Close()

    w, err := try(os.Create(dst))

    defer w.Close()
    defer os.Remove(dst)
    try(io.Copy(w, r))
    try(w.Close())

    return nil
}

Puede ver esto a primera vista y pensar que se ve mejor, porque hay mucho menos código repetido. Sin embargo, fue muy fácil detectar todos los puntos que devolvió la función en el primer ejemplo. Todos tenían sangría y comenzaban con return , seguidos de un espacio. Esto se debe al hecho de que todas las devoluciones condicionales _deben_ estar dentro de bloques condicionales, por lo que se sangran según los estándares gofmt . return también es, como se indicó anteriormente, la única forma de salir de una función sin decir que ocurrió un error catastrófico. En el segundo ejemplo, solo hay un único return , por lo que parece que lo único que la función _ever_ debería devolver es nil . Las últimas dos llamadas try son fáciles de ver, pero las dos primeras son un poco más difíciles, y lo serían aún más si estuvieran anidadas en algún lugar, es decir, algo como proc := try(os.FindProcess(try(strconv.Atoi(os.Args[1])))) .

Regresar de una función parece haber sido algo "sagrado", por lo que personalmente creo que todos los puntos de salida de una función deben estar marcados con return .

Alguien ya implementó esto hace 5 años. Si estás interesado, puedes
prueba esta característica

https://noticias.ycombinator.com/item?id=20101417

Implementé try() en Go hace cinco años con un preprocesador AST y lo usé en proyectos reales, fue bastante bueno: https://github.com/lunixbochs/og

Aquí hay algunos ejemplos de mí utilizándolo en funciones de verificación de errores: https://github.com/lunixbochs/poxd/blob/master/tls.go#L13

Agradezco el esfuerzo que se hizo en esto. Creo que es la solución más go-ey que he visto hasta ahora. Pero creo que introduce un montón de trabajo al depurar. Desenvolver el intento y agregar un bloque if cada vez que depuro y volver a envolverlo cuando termino es tedioso. Y también tengo algo de vergüenza por la variable de error mágico que debo considerar. Nunca me ha molestado la comprobación explícita de errores, así que tal vez no sea la persona adecuada para preguntar. Siempre me pareció "listo para depurar".

@griesemer
Mi problema con el uso propuesto de defer como una forma de manejar el ajuste de errores es que el comportamiento del fragmento que mostré (repetido a continuación) no es AFAICT muy común, y debido a que es muy raro, puedo imaginar a las personas escribiendo esto pensando que funciona cuando no lo hace

Como ... un principiante no sabría esto, si tiene un error debido a esto, no dirá "por supuesto, necesito un retorno con nombre", se estresaría porque debería funcionar y no lo hace.

var err error
defer fmt.HandleErrorf(err);

try ya es demasiado mágico, por lo que también puede ir hasta el final y agregar ese valor de error implícito. Piensa en los principiantes, no en aquellos que conocen todos los matices del Go. Si no está lo suficientemente claro, no creo que sea la solución correcta.

O... No sugiera usar diferir de esta manera, intente otra forma que sea más segura pero aún legible.

@deanveloper Es cierto que esta propuesta (y, de hecho, cualquier propuesta que intente hacer lo mismo) eliminará las declaraciones return explícitamente visibles del código fuente; después de todo, ese es el objetivo de la propuesta, ¿no es así? Para eliminar el modelo de declaraciones if y returns que son todas iguales. Si desea conservar los return , no use try .

Estamos acostumbrados a reconocer inmediatamente las sentencias return (y las panic ) porque así es como se expresa este tipo de flujo de control en Go (y muchos otros lenguajes). No parece descabellado que también reconozcamos try como un flujo de control cambiante después de acostumbrarnos, tal como lo hacemos con return . No tengo ninguna duda de que un buen soporte IDE ayudará con esto también.

Tengo dos preocupaciones:

• las devoluciones con nombre han sido muy confusas, y esto las alienta con un caso de uso nuevo e importante
• esto desalentará agregar contexto a los errores

En mi experiencia, agregar contexto a los errores inmediatamente después de cada sitio de llamada es fundamental para tener un código que se pueda depurar fácilmente. Y las devoluciones con nombre han causado confusión para casi todos los desarrolladores de Go que conozco en algún momento.

Una preocupación estilística menor es que es desafortunado cuántas líneas de código ahora se incluirán en try(actualThing()) . Puedo imaginar ver la mayoría de las líneas en un código base envuelto en try() . Eso se siente desafortunado.

Creo que estas preocupaciones se abordarían con un ajuste:

a, b, err := myFunc()
check(err, "calling myFunc on %v and %v", a, b)

check() se comportaría de manera muy similar a try() , pero eliminaría el comportamiento de pasar los valores de retorno de la función de forma genérica y, en su lugar, proporcionaría la capacidad de agregar contexto. Todavía desencadenaría un regreso.

Esto conservaría muchas de las ventajas de try() :

• es un incorporado
• sigue el flujo de control existente WRT para diferir
• se alinea bien con la práctica existente de agregar contexto a los errores
• se alinea con las propuestas y bibliotecas actuales para corregir errores, como errors.Wrap(err, "context message")
• da como resultado un sitio de llamada limpio: no hay texto estándar en la línea a, b, err := myFunc()
• Todavía es posible describir errores con defer fmt.HandleError(&err, "msg") , pero no es necesario alentarlo.
• la firma de check es un poco más simple, porque no necesita devolver un número arbitrario de argumentos de la función que está envolviendo.

@ s4n-gt Gracias por este enlace. Yo no era consciente de ello.

@Goodwine Punto tomado. La razón por la que no se proporciona soporte de manejo de errores más directo se analiza en detalle en el documento de diseño. También es un hecho que en el transcurso de un año más o menos (desde los diseños preliminares publicados en el Gophercon del año pasado) no ha surgido ninguna solución satisfactoria para el manejo explícito de errores. Es por eso que esta propuesta omite esto a propósito (y en su lugar sugiere usar un defer ). Esta propuesta aún deja la puerta abierta para futuras mejoras en ese sentido.

La propuesta menciona cambiar las pruebas de paquetes para permitir que las pruebas y los puntos de referencia devuelvan un error. Aunque no sería "un cambio de biblioteca modesto", también podríamos considerar aceptar func main() error . Sería mucho más agradable escribir pequeños guiones. La semántica sería equivalente a:

func main() {
  if err := newmain(); err != nil {
    println(err.Error())
    os.Exit(1)
  }
}

Una última crítica. No es realmente una crítica a la propuesta en sí, sino una crítica a una respuesta común al contraargumento de la "función que controla el flujo".

La respuesta a "No me gusta que una función controle el flujo" es que "¡ panic también controla el flujo del programa!". Sin embargo, hay algunas razones por las que está bien que panic haga esto que no se aplican a try .

1. panic es amigable para los programadores principiantes porque lo que hace es intuitivo, continúa desenvolviendo la pila. Ni siquiera debería tener que buscar cómo funciona panic para entender lo que hace. Los programadores principiantes ni siquiera necesitan preocuparse por recover , ya que los principiantes no suelen construir mecanismos de recuperación de pánico, especialmente porque casi siempre son menos favorables que simplemente evitar el pánico en primer lugar.

2. panic es un nombre fácil de ver. Trae preocupación, y necesita hacerlo. Si uno ve panic en un código base, debería pensar inmediatamente en cómo _evitar_ el pánico, incluso si es trivial.

3. Aprovechando el último punto, panic no se puede anidar en una llamada, lo que lo hace aún más fácil de ver.

Está bien que panic controle el flujo del programa porque es extremadamente fácil de detectar y es intuitivo en cuanto a lo que hace.

La función try no satisface ninguno de estos puntos.

1. Uno no puede adivinar lo que hace try sin consultar la documentación correspondiente. Muchos idiomas usan la palabra clave de diferentes maneras, lo que dificulta entender lo que significaría en Go.

2. try no me llama la atención, especialmente cuando es una función. _Especialmente_ cuando el resaltado de sintaxis lo resaltará como una función. _ESPECIALMENTE_ después de desarrollar en un lenguaje como Java, donde try se considera un modelo innecesario (debido a las excepciones comprobadas).

3. try se puede usar en un argumento para una llamada de función, según mi ejemplo en mi comentario anterior proc := try(os.FindProcess(try(strconv.Atoi(os.Args[1])))) . Esto hace que sea aún más difícil de detectar.

Mis ojos ignoran las funciones try , incluso cuando las estoy buscando específicamente. Mis ojos los verán, pero inmediatamente pasarán a las llamadas os.FindProcess o strconv.Atoi . try es una devolución condicional. El flujo de control Y los retornos se sostienen sobre pedestales en Go. Todo el flujo de control dentro de una función está sangrado y todos los retornos comienzan con return . La combinación de estos dos conceptos en una llamada de función fácil de perder se siente un poco fuera de lugar.

Sin embargo, este comentario y el último son mis únicas críticas reales a la idea. Creo que puede parecer que no me gusta esta propuesta, pero sigo pensando que es una victoria general para Go. Esta solución todavía se siente más parecida a Go que las otras soluciones. Si se agregara esto, estaría feliz, sin embargo, creo que aún se puede mejorar, pero no estoy seguro de cómo.

@buchanae interesante. Sin embargo, tal como está escrito, mueve el formato de estilo fmt de un paquete al lenguaje mismo, lo que abre una lata de gusanos.

Sin embargo, tal como está escrito, mueve el formato de estilo fmt de un paquete al lenguaje mismo, lo que abre una lata de gusanos.

Buen punto. Un ejemplo más simple:

a, b, err := myFunc()
check(err, "calling myFunc")

@buchanae Hemos considerado hacer que el manejo explícito de errores esté más directamente relacionado con try ; consulte el documento de diseño detallado, específicamente la sección sobre iteraciones de diseño. Su sugerencia específica de check solo permitiría aumentar los errores a través de algo como una API similar a fmt.Errorf (como parte de check ), si entiendo correctamente. En general, la gente puede querer hacer todo tipo de cosas con errores, no solo crear uno nuevo que se refiera al original a través de su cadena de error.

Nuevamente, esta propuesta no intenta resolver todas las situaciones de manejo de errores. Sospecho que en la mayoría de los casos try tiene sentido para el código que ahora se ve básicamente así:

a, b, c, ... err := try(someFunctionCall())
if err != nil {
   return ..., err
}

Hay una gran cantidad de código que se parece a esto. Y no todos los fragmentos de código que se ven así necesitan más manejo de errores. Y donde defer no es correcto, todavía se puede usar una instrucción if .

No sigo esta línea:

defer fmt.HandleErrorf(&err, “foobar”)

Deja caer el error de entrada en el piso, lo cual es inusual. ¿Está destinado a ser usado algo más como esto?

defer fmt.HandleErrorf(&err, “foobar: %v”, err)

La duplicación de err es un poco tartamuda. En realidad, esto no se relaciona directamente con la propuesta, solo es un comentario adicional sobre el documento.

Comparto las dos preocupaciones planteadas por @buchanae , re: devoluciones nombradas y errores contextuales.

Considero que named devuelve un poco problemático tal como es; Creo que solo son realmente beneficiosos como documentación. Apoyarse en ellos más fuertemente es una preocupación. Sin embargo, siento ser tan vago. Pensaré más en esto y proporcionaré algunos pensamientos más concretos.

Creo que existe una preocupación real de que las personas se esfuercen por estructurar su código para que se pueda usar try y, por lo tanto, evitar agregar contexto a los errores. Este es un momento particularmente extraño para presentar esto, dado que ahora estamos brindando mejores formas de agregar contexto a los errores a través de las funciones oficiales de ajuste de errores.

Creo que try según lo propuesto hace que algunos códigos sean mucho más agradables. Aquí hay una función que elegí más o menos al azar de la base de código de mi proyecto actual, con algunos de los nombres cambiados. Estoy particularmente impresionado por cómo funciona try cuando se asigna a campos de estructura. (¿Eso supone que mi lectura de la propuesta es correcta y que esto funciona?)

El código existente:

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        err := dbfile.RunMigrations(db, dbMigrations)
        if err != nil {
                return nil, err
        }
        t := &Thing{
                thingy: thingy,
        }
        t.scanner, err = newScanner(thingy, db, client)
        if err != nil {
                return nil, err
        }
        t.initOtherThing()
        return t, nil
}

Con try :

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        try(dbfile.RunMigrations(db, dbMigrations))
        t := &Thing{
                thingy:  thingy,
                scanner: try(newScanner(thingy, db, client)),
        }
        t.initOtherThing()
        return t, nil
}

Sin pérdida de legibilidad, excepto quizás que es menos obvio que newScanner podría fallar. Pero entonces, en un mundo con try Go, los programadores serían más sensibles a su presencia.

@josharian Con respecto a main que devuelve un error : me parece que su pequeña función auxiliar es todo lo que se necesita para obtener el mismo efecto. No estoy seguro de que se justifique cambiar la firma de main .

Con respecto al ejemplo de "foobar": es solo un mal ejemplo. Probablemente debería cambiarlo. Gracias por sacar el tema.

defer fmt.HandleErrorf(&err, “foobar: %v”, err)

En realidad, eso no puede ser correcto, porque err se evaluará demasiado pronto. Hay un par de formas de evitar esto, pero ninguna tan limpia como el HandleErrorf original (creo defectuoso). Creo que sería bueno tener uno o dos ejemplos prácticos más realistas de una función auxiliar.

EDITAR: este error de evaluación temprana está presente en un ejemplo
cerca del final del documento:

defer fmt.HandleErrorf(&err, "copy %s %s: %v", src, dst, err)

@adg Sí, try se puede usar como lo está usando en su ejemplo. Dejo que sus comentarios sobre: ​​las devoluciones nombradas permanezcan como están.

la gente puede querer hacer todo tipo de cosas con errores, no solo crear uno nuevo que se refiera al original a través de su cadena de error.

try no intenta manejar todos los tipos de cosas que la gente quiere hacer con los errores, solo aquellos que podemos encontrar una manera práctica de simplificar significativamente. Creo que mi ejemplo check sigue la misma línea.

En mi experiencia, la forma más común de código de manejo de errores es el código que esencialmente agrega un seguimiento de pila, a veces con contexto agregado. Descubrí que el seguimiento de la pila es muy importante para la depuración, donde sigo un mensaje de error a través del código.

Pero, ¿tal vez otras propuestas agregarán seguimientos de pila a todos los errores? He perdido la pista.

En el ejemplo que dio @adg , hay dos fallas potenciales pero no hay contexto. Si newScanner y RunMigrations no brindan mensajes que le indiquen cuál salió mal, entonces no sabe qué hacer.

En el ejemplo que dio @adg , hay dos fallas potenciales pero no hay contexto. Si newScanner y RunMigrations no brindan mensajes que le den una pista sobre cuál salió mal, entonces tiene que adivinar.

Así es, y esa es la elección de diseño que hicimos en este código en particular. Envolvemos muchos errores en otras partes del código.

Comparto la preocupación como @deanveloper y otros de que podría dificultar la depuración. Es cierto que podemos optar por no usarlo, pero los estilos de las dependencias de terceros no están bajo nuestro control.
Si el punto principal es if err := ... { return err } menos repetitivo, me pregunto si sería suficiente un "retorno condicional", como https://github.com/golang/go/issues/27794 propuesto.

        return nil, err if f, err := os.Open(...)
        return nil, err if _, err := os.Write(...)

Creo que ? encajaría mejor que try , y tener que perseguir siempre el defer por error también sería complicado.

Esto también cierra las puertas para tener excepciones usando try/catch para siempre.

Esto también cierra las puertas para tener excepciones usando try/catch para siempre.

Estoy _más_ que bien con esto.

Estoy de acuerdo con algunas de las preocupaciones planteadas anteriormente con respecto a agregar contexto a un error. Poco a poco estoy tratando de pasar de solo devolver un error a decorarlo siempre con un contexto y luego devolverlo. Con esta propuesta, tendré que cambiar por completo mi función para usar parámetros de retorno con nombre (lo cual me parece extraño porque apenas uso retornos desnudos).

Como dice @griesemer :

Nuevamente, esta propuesta no intenta resolver todas las situaciones de manejo de errores. Sospecho que en la mayoría de los casos, intentar tiene sentido para el código que ahora se ve básicamente así:
a, b, c, ... err := try(someFunctionCall())
si yerra != nil {
volver..., err
}
Hay una gran cantidad de código que se parece a esto. Y no todos los fragmentos de código que se ven así necesitan más manejo de errores. Y donde defer no es correcto, aún se puede usar una declaración if.

Sí, pero ¿no debería el buen código idiomático siempre envolver/decorar sus errores? Creo que es por eso que estamos introduciendo mecanismos refinados de manejo de errores para agregar errores de ajuste/contexto en stdlib. Como veo, esta propuesta solo parece considerar el caso de uso más básico.

Además, esta propuesta aborda solo el caso de envolver/decorar múltiples sitios de retorno de error posibles en un _lugar único_, utilizando parámetros con nombre con una llamada diferida.

Pero no hace nada en el caso de que se necesite agregar diferentes contextos a diferentes errores en una sola función. Por ejemplo, es muy esencial decorar los errores de la base de datos para obtener más información sobre su procedencia (suponiendo que no haya rastros de pila)

Este es un ejemplo de un código real que tengo:

func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    if err != nil {
        return err
    }
    var res int64
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    if err != nil {
        tx.Rollback()
        return fmt.Errorf("insert table: %w", err)
    }

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    if err != nil {
        tx.Rollback()
        return fmt.Errorf("insert table2: %w", err)
    }
    return tx.Commit()
}

Según la propuesta:

Si se desea aumentar o ajustar el error, hay dos enfoques: seguir con la declaración if probada y verdadera o, alternativamente, "declarar" un controlador de errores con una declaración diferida:

Creo que esto caerá en la categoría de "seguir con la declaración if probada y verdadera". Espero que la propuesta se pueda mejorar para abordar esto también.

Sugiero encarecidamente que el equipo de Go priorice los genéricos , ya que es donde Go escucha la mayoría de las críticas, y espere a que se solucionen los errores. La técnica de hoy no es tan dolorosa (aunque go fmt debería dejarlo reposar en una línea).

El concepto try() tiene todos los problemas de check de check/handle:

1. No se lee como Go. La gente quiere sintaxis de asignación, sin la subsiguiente prueba nula, ya que se parece a Go. Trece respuestas separadas para verificar/manejar sugirieron esto; ver _Temas recurrentes_ aquí:
   https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -temas

   f, #      := os.Open(...) // return on error
   f, #panic := os.Open(...) // panic on error
   f, #hname := os.Open(...) // invoke named handler on error
   // # is any available symbol or unambiguous pair
   

2. El anidamiento de llamadas a funciones que devuelven errores oscurece el orden de las operaciones y dificulta la depuración. El estado de cosas cuando ocurre un error, y por lo tanto la secuencia de llamadas, debería ser claro, pero aquí no lo es:
   try(step4(try(step1()), try(step3(try(step2())))))
   Ahora recuerda que el lenguaje prohíbe:
   f(t ? a : b) y f(a++)

3. Sería trivial devolver errores sin contexto. Una razón clave de verificar/manejar fue fomentar la contextualización.

4. Está vinculado al tipo error y al último valor devuelto. Si necesitamos inspeccionar otros valores/tipos de devolución para un estado excepcional, volvemos a: if errno := f(); errno != 0 { ... }

5. No ofrece múltiples caminos. El código que llama a las API de almacenamiento o redes maneja dichos errores de manera diferente a los que se deben a una entrada incorrecta o a un estado interno inesperado. Mi código hace uno de estos con mucha más frecuencia que return err :

   • registro.Fatal()
   • panic() para errores que nunca deberían surgir
   • registra un mensaje y vuelve a intentarlo

@gopherbot agrega Go2, Cambio de idioma

¿Qué tal usar solo ? para desenvolver el resultado como rust

La razón por la que somos escépticos acerca de llamar a try() puede ser dos enlaces implícitos. No podemos ver el enlace para el error de valor devuelto y los argumentos para try(). Para probar (), podemos hacer una regla que debemos usar try () con la función de argumento que tiene un error en los valores de retorno. Pero el enlace a los valores devueltos no lo es. Así que estoy pensando que se requiere más expresión para que los usuarios entiendan lo que hace este código.

func doSomething() (int, %error) {
  f := try(foo())
  ...
}

• No podemos usar try() si doSomething no tiene %error en los valores de retorno.
• No podemos usar try() si foo() no tiene un error en el último de los valores devueltos.

Es difícil agregar nuevos requisitos/características a la sintaxis existente.

Para ser honesto, creo que foo() también debería tener %error.

Agregar 1 regla más

• %error solo puede ser uno en la lista de valores de retorno de una función.

En el documento de diseño detallado noté que en una iteración anterior se sugirió pasar un controlador de errores a la función incorporada de prueba. Me gusta esto:

handler := func(err error) error {
        return fmt.Errorf("foo failed: %v", err)  // wrap error
}

f := try(os.Open(filename), handler)  

o incluso mejor, así:

f := try(os.Open(filename), func(err error) error {
        return fmt.Errorf("foo failed: %v", err)  // wrap error
})  

Aunque, como dice el documento, esto plantea varias preguntas, creo que esta propuesta sería mucho más deseable y útil si hubiera mantenido esta posibilidad de especificar opcionalmente dicha función de controlador de errores o cierre.

En segundo lugar, no me importa que una función incorporada pueda hacer que la función regrese, pero, para resumir un poco, el nombre 'intentar' es demasiado corto para sugerir que puede causar un regreso. Así que me parece mejor un nombre más largo, como attempt .

EDITAR: en tercer lugar, idealmente, el lenguaje go debería obtener genéricos primero, donde un caso de uso importante sería la capacidad de implementar esta función de prueba como un genérico, para que la eliminación de bicicletas pueda terminar y todos puedan obtener el manejo de errores que prefieran.

Las noticias de hackers tienen algo de razón: try no se comporta como una función normal (puede regresar), por lo que no es bueno darle una sintaxis similar a la de una función. Una sintaxis return o defer sería más apropiada:

func CopyFile(src, dst string) (err error) {
        r := try os.Open(src)
        defer r.Close()

        w := try os.Create(dst)
        defer func() {
                w.Close()
                if err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        try io.Copy(w, r)
        try w.Close()
        return nil
}

@sheerun, el contraargumento común a esto es que panic también es una función incorporada que altera el flujo de control. Personalmente no estoy de acuerdo con eso, sin embargo, es correcto.

1. Haciéndonos eco de @deanveloper arriba , así como los comentarios similares de otros, me temo que estamos subestimando los costos de agregar una palabra clave nueva, algo sutil y, especialmente cuando está integrada en otras llamadas a funciones, que se pasa por alto fácilmente y que administra el control de la pila de llamadas. flujo. panic(...) es una excepción relativamente clara (juego de palabras no intencionado) a la regla de que return es la única forma de salir de una función. No creo que debamos usar su existencia como justificación para agregar un tercero.
2. Esta propuesta canonizaría la devolución de un error no envuelto como el comportamiento predeterminado y relegaría los errores de envuelto como algo que tiene que aceptar, con una ceremonia adicional. Pero, en mi experiencia, eso es precisamente lo contrario a las buenas prácticas. Espero que una propuesta en este espacio facilite, o al menos no dificulte, agregar información contextual a los errores en el sitio del error.

tal vez podamos agregar una variante con función de aumento opcional algo así como tryf con esta semántica:

func tryf(t1 T1, t1 T2, … tn Tn, te error, fn func(error) error) (T1, T2, … Tn)

traduce esto

x1, x2, … xn = tryf(f(), func(err error) { return fmt.Errorf("foobar: %q", err) })

dentro de esto

t1, … tn, te := f()
if te != nil {
    if fn != nil {
        te = fn(te)
    }
    err = te
    return
}

dado que esta es una opción explícita (en lugar de usar try ), podemos encontrar respuestas razonables a las preguntas en la versión anterior de este diseño. por ejemplo, si la función de aumento es nula, no haga nada y simplemente devuelva el error original.

Me preocupa que try reemplace el manejo tradicional de errores y que, como resultado, haga que anotar las rutas de error sea más difícil.

El código que maneja los errores mediante el registro de mensajes y la actualización de los contadores de telemetría será considerado como defectuoso o inadecuado tanto por los linters como por los desarrolladores que esperan try todo.

a, b, err := doWork()
if err != nil {
  updateCounters()
  writeLogs()
  return err
}

Go es un lenguaje extremadamente social con modismos comunes impuestos por herramientas (fmt, lint, etc.). Tenga en cuenta las ramificaciones sociales de esta idea: habrá una tendencia a querer usarla en todas partes.

@politician , lo siento, pero la palabra que buscas no es _social_ sino _opinionario_. Go es un lenguaje de programación obstinado. Por lo demás, en general estoy de acuerdo con lo que dices.

Las herramientas de la comunidad @beoran como Godep y los diversos linters demuestran que Go es obstinado y social, y muchos de los dramas con el lenguaje se derivan de esa combinación. Con suerte, ambos podemos estar de acuerdo en que try no debería ser el próximo drama.

@politician Gracias por aclarar, no lo había entendido así. Ciertamente puedo estar de acuerdo en que debemos tratar de evitar el drama.

Estoy confundido al respecto.

Del blog: Los errores son valores , desde mi perspectiva, está diseñado para ser valorado, no para ser ignorado.

Y sí creo lo que dijo Rop Pike: "Los valores se pueden programar, y dado que los errores son valores, los errores se pueden programar".

No deberíamos considerar error como exception , es como importar complejidad no solo para pensar sino también para codificar si lo hacemos.

"Use el lenguaje para simplificar el manejo de errores". --Rob Pike

Y más, podemos revisar esta diapositiva

Una situación en la que encuentro la verificación de errores a través if particularmente incómoda es al cerrar archivos (por ejemplo, en NFS). Supongo que, actualmente, estamos destinados a escribir lo siguiente, si es posible que se produzcan devoluciones de error de .Close() .

r, err := os.Open(src)
if err != nil {
    return err
}
defer func() {
    // maybe check whether a previous error occured?
    return r.Close()
}()

¿Podría defer try(r.Close()) ser una buena forma de tener una sintaxis manejable para solucionar este tipo de errores? Al menos, tendría sentido ajustar el ejemplo de CopyFile() en la propuesta de alguna manera, para no ignorar los errores de r.Close() y w.Close() .

@seehuhn Su ejemplo no se compilará porque la función diferida no tiene un tipo de devolución.

func doWork() (err error) {
  r, err := os.Open(src)
  if err != nil {
    return err
  }
  defer func() {
    err = r.Close()  // overwrite the return value
  }()
}

Funcionará como esperas. La clave es el valor de retorno nombrado.

Me gusta la propuesta, pero creo que el ejemplo de @seehuhn también debería abordarse:

defer try(w.Close())

devolvería el error de Close() solo si el error aún no estaba configurado.
Este patrón se usa tan a menudo...

Estoy de acuerdo con las preocupaciones sobre agregar contexto a los errores. Lo veo como una de las mejores prácticas que mantiene los mensajes de error mucho más amigables (y claros) y facilita el proceso de depuración.

Lo primero que pensé fue reemplazar el fmt.HandleErrorf con una función tryf , que prefija el error con contexto adicional.

func tryf(t1 T1, t1 T2, … tn Tn, te error, ts string) (T1, T2, … Tn)

Por ejemplo (de un código real que tengo):

func (c *Config) Build() error {
    pkgPath, err := c.load()
    if err != nil {
        return nil, errors.WithMessage(err, "load config dir")
    }
    b := bytes.NewBuffer(nil)
    if err = templates.ExecuteTemplate(b, "main", c); err != nil {
        return nil, errors.WithMessage(err, "execute main template")
    }
    buf, err := format.Source(b.Bytes())
    if err != nil {
        return nil, errors.WithMessage(err, "format main template")
    }
    target := fmt.Sprintf("%s.go", filename(pkgPath))
    if err := ioutil.WriteFile(target, buf, 0644); err != nil {
        return nil, errors.WithMessagef(err, "write file %s", target)
    }
    // ...
}

Se puede cambiar a algo como:

func (c *Config) Build() error {
    pkgPath := tryf(c.load(), "load config dir")
    b := bytes.NewBuffer(nil)
    tryf(emplates.ExecuteTemplate(b, "main", c), "execute main template")
    buf := tryf(format.Source(b.Bytes()), "format main template")
    target := fmt.Sprintf("%s.go", filename(pkgPath))
    tryf(ioutil.WriteFile(target, buf, 0644), fmt.Sprintf("write file %s", target))
    // ...
}

O, si tomo el ejemplo de @agnivade :

func (p *pgStore) DoWork() (err error) {
    tx := tryf(p.handle.Begin(), "begin transaction")
        defer func() {
        if err != nil {
            tx.Rollback()
        }
    }()
    var res int64
    tryf(tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res), "insert table")
    _, = tryf(tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res), "insert table2")
    return tryf(tx.Commit(), "commit transaction")
}

Sin embargo, @josharian planteó un buen punto que me hace dudar sobre esta solución:

Sin embargo, tal como está escrito, mueve el formato de estilo fmt de un paquete al lenguaje mismo, lo que abre una lata de gusanos.

Estoy totalmente de acuerdo con esta propuesta y puedo ver sus beneficios a través de varios ejemplos.

Mi única preocupación con la propuesta es el nombre de try , siento que sus connotaciones con otros idiomas pueden distorsionar las percepciones de los desarrolladores sobre cuál es su propósito cuando proviene de otros idiomas. Java viene a buscar aquí.

Para mí, preferiría que la función integrada se llamara pass . Siento que esto da una mejor representación de lo que está sucediendo. Después de todo, no está manejando el error, sino devolviéndolo para que lo maneje la persona que llama. try da la impresión de que se ha manejado el error.

Es un pulgar hacia abajo de mi parte, principalmente porque el problema que pretende abordar ("las declaraciones repetitivas if típicamente asociadas con el manejo de errores") simplemente no es un problema para mí. Si todas las comprobaciones de errores fueran simplemente if err != nil { return err } entonces podría ver algún valor en agregar azúcar sintáctico para eso (aunque Go es un lenguaje relativamente libre de azúcar por inclinación).

De hecho, lo que quiero hacer en caso de un error no nulo varía considerablemente de una situación a otra. Tal vez quiera t.Fatal(err) . Tal vez quiera agregar un mensaje de decoración return fmt.Sprintf("oh no: %v", err) . Tal vez solo registro el error y continúo. Tal vez configuré un indicador de error en mi objeto SafeWriter y continué, verificando el indicador al final de alguna secuencia de operaciones. Quizá deba tomar otras medidas. Ninguno de estos se puede automatizar con try . Entonces, si el argumento para try es que eliminará todos los bloques if err != nil , ese argumento no se sostiene.

¿Eliminará _algunos_ de ellos? Por supuesto. ¿Es una propuesta atractiva para mí? Meh. Realmente no estoy preocupado. Para mí, if err != nil es solo parte de Go, como las llaves, o defer . Entiendo que parece detallado y repetitivo para las personas que son nuevas en Go, pero las personas que son nuevas en Go no son las más indicadas para realizar cambios drásticos en el idioma, por un montón de razones.

Tradicionalmente, el estándar para cambios significativos en Go ha sido que el cambio propuesto debe resolver un problema que es (A) significativo, (B) afecta a muchas personas y (C) está bien resuelto por la propuesta. No estoy convencido de ninguno de estos tres criterios. Estoy muy contento con el manejo de errores de Go tal como está.

Para hacer eco de @peterbourgon y @deanveloper , una de mis cosas favoritas de Go es que el flujo de código es claro y panic() no se trata como un mecanismo de control de flujo estándar como lo es en Python.

En cuanto al debate sobre panic, panic() casi siempre aparece solo en una línea porque no tiene ningún valor. No puedes fmt.Println(panic("oops")) . Esto aumenta enormemente su visibilidad y lo hace mucho menos comparable a try() de lo que la gente cree.

Si va a haber otra construcción de control de flujo para funciones, preferiría _mucho_ que sea una declaración garantizada para ser el elemento más a la izquierda en una línea.

Uno de los ejemplos en la propuesta me aclara el problema:

func printSum(a, b string) error {
        fmt.Println(
                "result:",
                try(strconv.Atoi(a)) + try(strconv.Atoi(b)),
        )
        return nil
}

El flujo de control realmente se vuelve menos obvio y muy oscuro.

Esto también va en contra de la intención inicial de Rob Pike de que todos los errores deben manejarse explícitamente.

Si bien una reacción a esto puede ser "entonces no lo use", el problema es que otras bibliotecas lo usarán, y depurarlos, leerlos y usarlos se vuelve más problemático. Esto motivará a mi empresa a nunca adoptar go 2 y comenzar a usar solo bibliotecas que no usan try . Si no estoy solo con esto, podría conducir a una división a-la python 2/3.

Además, la denominación de try implicará automáticamente que eventualmente catch aparecerá en la sintaxis, y volveremos a ser Java.

Entonces, por todo esto, estoy _fuertemente_ en contra de esta propuesta.

No me gusta el nombre try . Implica un _intento_ de hacer algo con un alto riesgo de fallar (puedo tener un sesgo cultural en contra de _intentar_ ya que no soy un hablante nativo de inglés), mientras que en su lugar se usaría try en caso de que esperemos fallas raras (motivación para querer reducir la verbosidad del manejo de errores) y son optimistas. Además try en esta propuesta de hecho _capta_ un error para devolverlo antes de tiempo. Me gusta la sugerencia de pass de @HiImJC.

Además del nombre, me resulta incómodo tener una declaración similar a return ahora oculta en medio de las expresiones. Esto rompe el estilo Go flow. Hará que las revisiones de código sean más difíciles.

En general, encuentro que esta propuesta solo beneficiará al programador perezoso que ahora tiene un arma para un código más corto y aún menos razones para hacer el esfuerzo de envolver errores. Como también dificultará las revisiones (retorno en medio de la expresión), creo que esta propuesta va en contra del objetivo de "programación a escala" de Go.

Una de mis cosas favoritas sobre Go que generalmente digo cuando describo el idioma es que solo hay una forma de hacer las cosas, para la mayoría de las cosas. Esta propuesta va un poco en contra de ese principio al ofrecer múltiples formas de hacer lo mismo. Personalmente, creo que esto no es necesario y que quitaría, en lugar de agregar, simplicidad y legibilidad al lenguaje.

Me gusta esta propuesta en general. La interacción con defer parece suficiente para proporcionar una forma ergonómica de devolver un error al tiempo que agrega contexto adicional. Aunque sería bueno abordar el inconveniente que @josharian señaló sobre cómo incluir el error original en el mensaje de error envuelto.

Lo que falta es una forma ergonómica de interactuar con la(s) propuesta(s) de inspección de errores sobre la mesa. Creo que las API deben ser muy deliberadas sobre qué tipos de errores devuelven, y el valor predeterminado probablemente debería ser "los errores devueltos no son inspeccionables de ninguna manera". Entonces debería ser fácil ir a un estado donde los errores sean inspeccionables de manera precisa, como lo documenta la firma de la función ("Informa un error de tipo X en la circunstancia A y un error de tipo Y en la circunstancia B").

Desafortunadamente, a partir de ahora, esta propuesta hace que la opción más ergonómica sea la más indeseable (para mí); pasando ciegamente a través de tipos de error arbitrarios. Creo que esto no es deseable porque fomenta no pensar en los tipos de errores que devuelve y cómo los consumirán los usuarios de su API. La conveniencia adicional de esta propuesta es ciertamente agradable, pero me temo que fomentará el mal comportamiento porque la conveniencia percibida superará el valor percibido de pensar detenidamente qué información de error proporciona (o filtra).

Una curita sería si los errores devueltos por try se convirtieran en errores que no son "desenvolvibles". Desafortunadamente, esto también tiene desventajas bastante graves, ya que hace que cualquier defer no pueda inspeccionar los errores en sí. Además, evita el uso en el que try en realidad devolverá un error de tipo deseable (es decir, casos de uso en los que try se usa con cuidado en lugar de descuidarlo).

Otra solución sería reutilizar la idea (descartada) de tener un segundo argumento opcional para try para definir o incluir en la lista blanca los tipos de error que pueden devolverse desde ese sitio. Esto es un poco problemático porque tenemos dos formas diferentes de definir un "tipo de error", ya sea por valor ( io.EOF etc.) o por tipo ( *os.PathError , *exec.ExitError ). Es fácil especificar tipos de error que son valores como argumentos de una función, pero es más difícil especificar tipos. No estoy seguro de cómo manejar eso, pero lanzando la idea por ahí.

El problema que señaló @josharian se puede evitar retrasando la evaluación de err:

defer func() { fmt.HandleErrorf(&err, "oops: %v", err) }()

No se ve muy bien, pero debería funcionar. Sin embargo, preferiría que esto se solucione agregando un nuevo verbo/indicador de formato para los punteros de error, o tal vez para los punteros en general, que imprima el valor desreferenciado como %v simple. A los efectos del ejemplo, llamémoslo %*v :

defer fmt.HandleErrorf(&err, "oops: %*v", &err)

Dejando de lado el inconveniente, creo que esta propuesta parece prometedora, pero parece crucial para mantener bajo control la ergonomía de agregar contexto a los errores.

Editar:

Otro enfoque es envolver el puntero de error en una estructura que implementa Stringer :

type wraperr struct{ err *error }
func (w wraperr) String() string { return (*w.err).Error() }

...

defer handleErrorf(&err, "oops: %v", wraperr{&err})

Un par de cosas desde mi perspectiva. ¿Por qué nos preocupamos tanto por ahorrar algunas líneas de código? Considero esto en la misma línea que las funciones pequeñas consideradas dañinas .

Además, encuentro que tal propuesta eliminaría la responsabilidad de manejar correctamente el error a alguna "magia" de la que me preocupa que se abuse y fomente la pereza, lo que resultará en errores y código de mala calidad.

La propuesta, como se indicó, también tiene una serie de comportamientos poco claros, por lo que esto ya es problemático que ~3 líneas adicionales _explícitas_ que son más claras.

Actualmente usamos el patrón de aplazamiento con moderación en casa. Hay un artículo aquí que tuvo una recepción mixta similar cuando lo escribimos: https://bet365techblog.com/better-error-handling-in-go

Sin embargo, nuestro uso de él fue en previsión del progreso de la propuesta check / handle .

Verificar/manejar fue un enfoque mucho más completo para hacer que el manejo de errores fuera más conciso. Su bloque handle retuvo el mismo ámbito de función que el que se definió, mientras que cualquier instrucción defer son contextos nuevos con una cantidad, por grande que sea, de sobrecarga. Esto parecía estar más en consonancia con las expresiones idiomáticas de go, en el sentido de que si deseaba el comportamiento de "simplemente devolver el error cuando suceda", podría declararlo explícitamente como handle { return err } .

Defer obviamente depende de que la referencia de error también se mantenga, pero hemos visto que surgen problemas al sombrear la referencia de error con vars de ámbito de bloque. Por lo tanto, no es lo suficientemente infalible como para ser considerado la forma estándar de manejar errores en marcha.

try , en este caso, no parece resolver demasiado y comparto el mismo temor que otros de que simplemente conduciría a implementaciones perezosas, o que usarían en exceso el patrón de aplazamiento.

Si el manejo de errores basado en aplazamiento va a ser una cosa, entonces probablemente se debería agregar algo como esto al paquete de errores:

        f := try(os.Create(filename))
        defer errors.Deferred(&err, f.Close)

Ignorar los errores de las declaraciones de cierre diferidas es un problema bastante común. Debería haber una herramienta estándar para ayudar con eso.

Una función integrada que devuelve es más difícil de vender que una palabra clave que hace lo mismo.
Me gustaría más si fuera una palabra clave como lo es en Zig[1].

1. https://ziglang.org/documentation/master/#try

Las funciones integradas, cuya firma de tipo no se puede expresar usando el sistema de tipos del lenguaje, y cuyo comportamiento confunde lo que normalmente es una función, simplemente parece una escotilla de escape que se puede usar repetidamente para evitar la evolución real del lenguaje.

Estamos acostumbrados a reconocer inmediatamente declaraciones de retorno (y pánico) porque así es como se expresa este tipo de flujo de control en Go (y muchos otros lenguajes). No parece descabellado que también reconozcamos try como cambiar el flujo de control después de acostumbrarnos, al igual que lo hacemos con return. No tengo ninguna duda de que un buen soporte IDE ayudará con esto también.

Creo que es bastante exagerado. En código gofmt'ed, un retorno siempre coincide con /^\t*return / ; es un patrón muy trivial para detectar a simple vista, sin ninguna ayuda. try , por otro lado, puede ocurrir en cualquier parte del código, anidado arbitrariamente en profundidad en las llamadas a funciones. Ninguna cantidad de capacitación nos permitirá detectar de inmediato todo el flujo de control en una función sin la ayuda de herramientas.

Además, una función que dependa de un "buen soporte IDE" estará en desventaja en todos los entornos donde no haya un buen soporte IDE. Las herramientas de revisión de código me vienen a la mente de inmediato: ¿Gerrit me resaltará todos los intentos? ¿Qué pasa con las personas que optan por no usar IDE o resaltado de código elegante por varias razones? ¿Acme comenzará a resaltar try ?

Una función de idioma debe ser fácil de entender por sí misma, no depender del soporte del editor.

@kungfusheep Me gusta ese artículo. Solo ocuparse de envolver en un aplazamiento ya aumenta bastante la legibilidad sin try .

Estoy en el campamento que no siente que los errores en Go sean realmente un problema. Aun así, if err != nil { return err } puede ser bastante tartamudo en algunas funciones. He escrito funciones que necesitaban una comprobación de errores después de casi todas las declaraciones y ninguna necesitaba un manejo especial que no fuera el ajuste y devolución. A veces simplemente no hay ninguna estructura de búfer inteligente que mejore las cosas. A veces es solo un paso crítico diferente tras otro y simplemente necesita hacer un cortocircuito si algo salió mal.

Aunque try sin duda haría que el código fuera mucho más fácil de leer y agradable al mismo tiempo que es totalmente compatible con versiones anteriores, estoy de acuerdo en que try no es una característica crítica que debe tener, por lo que si la gente tiene demasiado miedo de tal vez sea mejor no tenerlo.

Sin embargo, la semántica es bastante clara. Cada vez que vea try , está siguiendo el camino feliz o regresa. Realmente no puedo ser más simple que eso.

Esto parece una macro encapsulada especial.

@dominikh try siempre coincide con /try\(/ así que no sé cuál es realmente tu punto. Es igual de buscable y todos los editores de los que he oído hablar tienen una función de búsqueda.

@qrpnxz Creo que el punto que estaba tratando de hacer no es que no puedas buscarlo programáticamente, sino que es más difícil buscarlo con tus ojos. La expresión regular era solo una analogía, con énfasis en /^\t* , lo que significa que todos los retornos se destacan claramente por estar al comienzo de una línea (ignorando los espacios en blanco iniciales).

Pensándolo más, debería haber un par de funciones auxiliares comunes. Quizás deberían estar en un paquete llamado "diferido".

Dirigiéndose a la propuesta de un check con formato para evitar nombrar la devolución, puede hacerlo con una función que verifique que no haya nada, así

func Format(err error, message string, args ...interface{}) error {
    if err == nil {
        return nil
    }
    return fmt.Errorf(...)
}

Esto se puede usar sin un retorno con nombre como este:

func foo(s string) (int, error) {
    n, err := strconv.Atoi(s)
    try(deferred.Format(err, "bad string %q", s))
    return n, nil
}

El fmt.HandleError propuesto podría colocarse en el paquete diferido en su lugar y mi función de ayuda "errors.Defer" podría llamarse deferred.Exec y podría haber un exec condicional para que los procedimientos se ejecuten solo si el error no es nulo.

Al juntarlo, obtienes algo como

func CopyFile(src, dst string) (err error) {
    defer deferred.Annotate(&err, "copy %s %s", src, dst)

    r := try(os.Open(src))
    defer deferred.Exec(&err, r.Close)

    w := try(os.Create(dst))
    defer deferred.Exec(&err, r.Close)

    defer deferred.Cond(&err, func(){ os.Remove(dst) })
    try(io.Copy(w, r))

    return nil
}

Otro ejemplo:

func (p *pgStore) DoWork() (err error) {
    tx := try(p.handle.Begin())

    defer deferred.Cond(&err, func(){ tx.Rollback() })

    var res int64 
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    try(deferred.Format(err, "insert table")

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    try(deferred.Format(err, "insert table2"))

    return tx.Commit()
}

Esta propuesta nos lleva de tener if err != nil todos lados, a tener try todos lados. Desplaza el problema propuesto y no lo resuelve.

Aunque, diría que, para empezar, el mecanismo actual de manejo de errores no es un problema. Solo necesitamos mejorar las herramientas y la investigación a su alrededor.

Además, diría que if err != nil es en realidad más legible que try porque no abarrota la línea del lenguaje de lógica empresarial, sino que se encuentra justo debajo:

file := try(os.OpenFile("thing")) // less readable than, 

file, err := os.OpenFile("thing")
if err != nil {

}

Y si Go iba a ser más mágico en su manejo de errores, ¿por qué no simplemente poseerlo por completo? Por ejemplo, Go puede llamar implícitamente al try incorporado si un usuario no asigna un error. Por ejemplo:

func getString() (string, error) { ... }

func caller() {
  defer func() {
    if err != nil { ... } // whether `err` must be defined or not is not shown in this example. 
  }

  // would call try internally, because a user is not 
  // assigning an error value. Also, it can add a compile error
  // for "defined and not used err value" if the user does not 
  // handle the error. 
  str := getString()
}

Para mí, eso resolvería el problema de la redundancia a costa de la magia y la legibilidad potencial.

Por lo tanto, propongo que realmente resolvamos el 'problema' como en el ejemplo anterior o mantengamos el manejo de errores actual, pero en lugar de cambiar el idioma para resolver la redundancia y el ajuste, no cambiamos el idioma pero mejoramos las herramientas y la verificación . de código para mejorar la experiencia.

Por ejemplo, en VSCode hay un fragmento llamado iferr si lo escribes y presionas enter, se expande a una declaración completa de manejo de errores... por lo tanto, escribirlo nunca me parece aburrido, y leerlo más adelante es mejor .

@josharian

Aunque no sería "un cambio de biblioteca modesto", también podríamos considerar aceptar el error func main().

El problema con eso es que no todas las plataformas tienen una semántica clara sobre lo que eso significa. Su reescritura funciona bien en los programas Go "tradicionales" que se ejecutan en un sistema operativo completo, pero tan pronto como escribe microcontrolador-firmware o incluso solo WebAssembly, no está muy claro qué significaría os.Exit(1) . Actualmente, os.Exit es una llamada de biblioteca, por lo que las implementaciones de Go son gratuitas solo para no proporcionarlo. Sin embargo, la forma de main es una preocupación del idioma.

Una pregunta sobre la propuesta que probablemente se responda mejor con "no": ¿Cómo interactúa try con argumentos variados? Es el primer caso de una función variadic (ish) que no tiene su variadic-nes en el último argumento. ¿Está permitido?

var e []error
try(e...)

Dejando de lado por qué alguna vez harías eso. Sospecho que la respuesta es "no" (de lo contrario, el seguimiento es "¿qué sucede si la longitud del segmento expandido es 0?").

• Varias de las mejores características de go son que las funciones integradas actuales aseguran un flujo de control claro, el manejo de errores es explícito y alentado, y los desarrolladores están fuertemente disuadidos de escribir código "mágico". La propuesta try no es coherente con estos principios básicos, ya que promoverá la taquigrafía a costa de la legibilidad del flujo de control.
• Si se adopta esta propuesta, quizás considere hacer que el try sea una declaración incorporada en lugar de una función . Entonces es más consistente con otras declaraciones de flujo de control como if . Además, la eliminación de los paréntesis anidados mejora marginalmente la legibilidad.
• Una vez más, si se adopta la propuesta, quizás se implemente sin usar defer o similar. Ya no se puede implementar de forma pura (como lo señalaron otros), por lo que también puede usar una implementación más eficiente bajo el capó.

Veo dos problemas con esto:

1. Pone MUCHO código anidado dentro de funciones. Eso agrega mucha carga cognitiva adicional, tratando de analizar el código en tu cabeza.

1. Nos da lugares donde el código puede salir desde el medio de una declaración.

Número 2, creo que es mucho peor. Todos los ejemplos aquí son llamadas simples que devuelven un error, pero lo que es mucho más insidioso es esto:

func doit(abc string) error {
    a := fmt.Sprintf("value of something: %s\n", try(getValue(abc)))
    log.Println(a)
    return nil
}

Este código puede salir en medio de ese sprintf, y será SÚPER fácil pasar por alto ese hecho.

Mi voto es no. Esto no mejorará el código go. No hará que sea más fácil de leer. No lo hará más robusto.

Lo he dicho antes, y esta propuesta lo ejemplifica: siento que el 90% de las quejas sobre Go son "No quiero escribir una declaración if o un bucle". Esto elimina algunas declaraciones if muy simples, pero agrega carga cognitiva y hace que sea fácil pasar por alto los puntos de salida de una función.

Solo quiero señalar que no podría usar esto en la página principal y podría ser confuso para los nuevos usuarios o al enseñar. Obviamente, esto se aplica a cualquier función que no devuelva un error, pero creo que main es especial ya que aparece en muchos ejemplos.

func main() {
    f := try(os.Open("foo.txt"))
    defer f.Close()
}

Tampoco estoy seguro de que hacer try panic en main sea aceptable.

Además, no sería particularmente útil en las pruebas ( func TestFoo(t* testing.T) ), lo cual es desafortunado :(

El problema que tengo con esto es que asume que siempre desea devolver el error cuando sucede. Cuando tal vez quiera agregar contexto al error y devolverlo o tal vez solo quiera comportarse de manera diferente cuando ocurre un error. Tal vez eso depende del tipo de error devuelto.

Preferiría algo parecido a un intento/captura que podría verse como

Suponiendo que foo() se define como

func foo() (int, error) {}

Entonces podrías hacer

n := try(foo()) {
    case FirstError:
        // do something based on FirstError
    case OtherError:
        // do something based on OtherError
    default:
        // default behavior for any other error
}

que se traduce en

n, err := foo()
if errors.Is(err, FirstError) {
    // do something based on FirstError
if errors.Is(err, OtherError) {
    // do something based on OtherError
} else {
    // default behavior for any other error
}

Para mí, el manejo de errores es una de las partes más importantes de un código base.
Ya hay demasiado código go if err != nil { return err } , que devuelve un error desde lo más profundo de la pila sin agregar contexto adicional, o incluso (posiblemente) peor agregando contexto enmascarando el error subyacente con fmt.Errorf envolviendo.

Proporcionar una nueva palabra clave que es una especie de magia que no hace más que reemplazar if err != nil { return err } parece un camino peligroso.
Ahora todo el código se envolverá en una llamada para probar. Esto está algo bien (aunque la legibilidad apesta) para el código que se ocupa solo de errores en el paquete, como:

func foo() error {
  /// stuff
  try(bar())
  // more stuff
}

Pero diría que el ejemplo dado es realmente horrible y básicamente deja a la persona que llama tratando de entender un error que está muy profundo en la pila, muy parecido al manejo de excepciones.
Por supuesto, todo depende del desarrollador para hacer lo correcto aquí, pero le da al desarrollador una excelente manera de no preocuparse por sus errores con tal vez un "arreglaremos esto más tarde" (y todos sabemos cómo funciona eso ).

Me gustaría que analizáramos el problema desde una perspectiva diferente a *"cómo podemos reducir la repetición" y más sobre "cómo podemos hacer que el manejo (adecuado) de errores sea más simple y que los desarrolladores sean más productivos".
Deberíamos pensar en cómo afectará esto a la ejecución del código de producción.

*Nota: Esto en realidad no reduce la repetición, solo cambia lo que se repite, al mismo tiempo que hace que el código sea menos legible porque todo está encerrado en un try() .

Un último punto: al principio, leer la propuesta parece agradable, luego comienzas a entender todos los problemas (al menos los enumerados) y es como "bueno, sí, esto es demasiado".

Me doy cuenta de que mucho de esto es subjetivo, pero es algo que me importa. Esta semántica es increíblemente importante.
Lo que quiero ver es una forma de simplificar la escritura y el mantenimiento del código de nivel de producción, de modo que también podría hacer los errores "correctamente", incluso para el código de nivel POC/demo.

Dado que el contexto de error parece ser un tema recurrente...

Hipótesis: la mayoría de las funciones de Go devuelven (T, error) en lugar de (T1, T2, T3, error)

¿Qué pasa si, en lugar de definir try como try(T1, T2, T3, error) (T1, T2, T3) lo definimos como
try(func (args) (T1, T2, T3, error))(T1, T2, T3) ? (esto es una aproximación)

lo que quiere decir que la estructura sintáctica de una llamada try es siempre un primer argumento que es una expresión que devuelve múltiples valores, el último de los cuales es un error.

Luego, al igual que make , esto abre la puerta a una forma de llamada de 2 argumentos, donde el segundo argumento es el contexto del intento (por ejemplo, una cadena fija, una cadena con un %v , una función que toma un argumento de error y devuelve otro error, etc.)

Esto aún permite el encadenamiento para el caso de (T, error) , pero ya no puede encadenar varias devoluciones, lo que, en mi opinión, normalmente no se requiere.

@ cpuguy83 Si lee la propuesta, verá que no hay nada que le impida envolver el error. De hecho, hay varias formas de hacerlo sin dejar de usar try . Sin embargo, muchas personas parecen asumir eso por alguna razón.

if err != nil { return err } es igual que "lo arreglaremos más tarde" como try excepto que es más molesto cuando se crean prototipos.

No sé cómo las cosas que están dentro de un par de paréntesis son menos legibles que los pasos de función que están cada cuatro líneas de repetitivo tampoco.

Sería bueno si señalaras algunos de estos "errores" particulares que te molestaron, ya que ese es el tema.

La legibilidad parece ser un problema, pero ¿qué pasa con go fmt presentando try() para que se destaque, algo como:

f := try(
    os.Open("file.txt")
)

@MrTravisB

El problema que tengo con esto es que asume que siempre desea devolver el error cuando sucede.

Estoy en desacuerdo. Se supone que desea hacerlo con la suficiente frecuencia como para garantizar una abreviatura para eso. Si no lo hace, no interfiere en el manejo de errores claramente.

Cuando tal vez quiera agregar contexto al error y devolverlo o tal vez solo quiera comportarse de manera diferente cuando ocurre un error.

La propuesta describe un patrón para agregar contexto de bloque completo a los errores. Sin embargo, @josharian señaló que hay un error en los ejemplos y no está claro cuál es la mejor manera de evitarlo. He escrito un par de ejemplos de formas de manejarlo.

Para un contexto de error más específico, nuevamente, try hace una cosa, y si no quiere esa cosa, no use try .

@boomlinde Exactamente mi punto. Esta propuesta intenta resolver un caso de uso singular en lugar de proporcionar una herramienta para resolver el problema más amplio del manejo de errores. Creo que la pregunta fundamental es exactamente lo que usted señaló.

Se supone que desea hacerlo con la suficiente frecuencia como para garantizar una abreviatura para eso.

En mi opinión y experiencia, este caso de uso es una pequeña minoría y no garantiza una sintaxis abreviada.

Además, el enfoque de usar defer para manejar errores tiene problemas en el sentido de que asume que desea manejar todos los errores posibles de la misma manera. Los extractos defer no se pueden cancelar.

defer fmt.HandleErrorf(&err, “foobar”)

n := try(foo())

x : try(foo2())

¿Qué pasa si quiero un manejo de errores diferente para los errores que pueden devolverse desde foo() frente a foo2() ?

@MrTravisB

¿Qué sucede si quiero un manejo de errores diferente para los errores que pueden devolverse desde foo() frente a foo2()?

Entonces usas otra cosa. Ese es el punto que @boomlinde estaba haciendo.

Tal vez usted personalmente no vea este caso de uso a menudo, pero mucha gente sí, y agregar try realmente no le afecta. De hecho, cuanto más raro es el caso de uso para usted, menos le afecta que se agregue try .

@qrpnxz

f := try(os.Open("/foo"))
data := try(ioutil.ReadAll(f))
try(send(data))

(sí, entiendo que hay ReadFile y que este ejemplo en particular no es la mejor manera de copiar datos en algún lugar, no es el punto)

Esto requiere más esfuerzo para leer porque tiene que analizar los intentos en línea. La lógica de la aplicación está envuelta en otra llamada.
También diría que un controlador de errores defer aquí no sería bueno, excepto para simplemente envolver el error con un nuevo mensaje... lo cual es bueno, pero hay más para lidiar con los errores que hacer que sea fácil para el humano para leer lo que pasó.

En rust, al menos, el operador es un sufijo ( ? agregado al final de una llamada) que no impone una carga adicional para desenterrar la lógica real.

Control de flujo basado en expresiones

panic puede ser otra función de control de flujo, pero no devuelve un valor, por lo que es efectivamente una declaración. Compare esto con try , que es una expresión y puede ocurrir en cualquier lugar.

recover tiene un valor y afecta el control de flujo, pero debe aparecer en una instrucción defer . Estos defer son típicamente funciones literales, recover solo se llama una vez, por lo que recover también aparece efectivamente como una declaración. Nuevamente, compare esto con try que puede ocurrir en cualquier lugar.

Creo que esos puntos significan que try hace que sea significativamente más difícil seguir el flujo de control de una manera que no hemos tenido antes, como se señaló anteriormente, pero no vi la distinción entre declaraciones y expresiones. señaló

otra propuesta

Permitir declaraciones como

if err != nil {
    return nil, 0, err
}

para ser formateado en una línea por gofmt cuando el bloque solo contiene una instrucción return y esa instrucción no contiene saltos de línea. Por ejemplo:

if err != nil { return nil, 0, err }

Razón fundamental

• No requiere cambios de idioma
• La regla de formato es simple y clara.
• La regla se puede diseñar para que se opte donde gofmt mantiene las líneas nuevas si ya existen (como los literales de estructura). Optar también le permite al escritor hacer énfasis en el manejo de errores
• Si no está habilitado, el código se puede transferir automáticamente al nuevo estilo con una llamada a gofmt
• Es solo para declaraciones de return , por lo que no se abusará del código de golf innecesariamente
• Interactúa bien con los comentarios que describen por qué pueden ocurrir algunos errores y por qué se devuelven. Usar muchas expresiones try anidadas maneja esto mal
• Reduce el espacio vertical de manejo de errores en un 66%
• Sin flujo de control basado en expresiones
• El código se lee con mucha más frecuencia de lo que se escribe, por lo que debe optimizarse para el lector. El código repetitivo que ocupa menos espacio es útil para el lector, donde try se inclina más hacia el escritor
• La gente ya ha estado proponiendo try existentes en varias líneas. Por ejemplo, este comentario o este comentario que introduce un estilo como

f, err := os.Open(file)
try(maybeWrap(err))

• El estilo "pruebe en su propia línea" elimina cualquier ambigüedad sobre err que se devuelve. Por lo tanto, sospecho que este formulario se usará comúnmente. Permitir uno forrado si los bloques son casi lo mismo, excepto que también es explícito sobre cuáles son los valores de retorno
• No promueve el uso de devoluciones con nombre o un envoltorio poco claro basado defer . Ambos elevan la barrera de los errores de ajuste y el primero puede requerir cambios godoc
• No es necesario discutir cuándo usar try en lugar de usar el manejo de errores tradicional
• No excluye hacer try o algo más en el futuro. El cambio puede ser positivo incluso si se acepta try
• Sin interacción negativa con la biblioteca $# testing 7$#$ o las funciones main . De hecho, si la propuesta permite cualquier declaración de una sola línea en lugar de solo devoluciones, puede reducir el uso de bibliotecas basadas en aserciones. Considerar

value, err := something()
if err != nil { t.Fatal(err) }

• No hay interacción negativa con la verificación de errores específicos. Considerar

n, err := src.Read(buf)
if err == io.EOF { return nil }
else if err != nil { return err }

En resumen, esta propuesta tiene un costo pequeño, se puede diseñar para ser opcional, no excluye más cambios ya que es solo de estilo y reduce el dolor de leer un código detallado de manejo de errores mientras mantiene todo explícito. Creo que al menos debería considerarse como un primer paso antes de apostar try .

Desde https://github.com/golang/go/issues/32437#issuecomment-498941435

con probar

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        try(dbfile.RunMigrations(db, dbMigrations))
        t := &Thing{
                thingy:  thingy,
                scanner: try(newScanner(thingy, db, client)),
        }
        t.initOtherThing()
        return t, nil
}

Con este

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        err := dbfile.RunMigrations(db, dbMigrations))
        if err != nil { return nil, fmt.Errorf("running migrations: %v", err) }

        t := &Thing{thingy: thingy}
        t.scanner, err = newScanner(thingy, db, client)
        if err != nil { return nil, fmt.Errorf("creating scanner: %v", err) }

        t.initOtherThing()
        return t, nil
}

Es competitivo en el uso del espacio al tiempo que permite agregar contexto a los errores.

Desde https://github.com/golang/go/issues/32437#issuecomment-499007288

con probar

func (c *Config) Build() error {
    pkgPath := try(c.load())
    b := bytes.NewBuffer(nil)
    try(emplates.ExecuteTemplate(b, "main", c))
    buf := try(format.Source(b.Bytes()))
    target := fmt.Sprintf("%s.go", filename(pkgPath))
    try(ioutil.WriteFile(target, buf, 0644))
    // ...
}

Con este

func (c *Config) Build() error {
    pkgPath, err := c.load()
    if err != nil { return nil, errors.WithMessage(err, "load config dir") }

    b := bytes.NewBuffer(nil)
    err = templates.ExecuteTemplate(b, "main", c)
    if err != nil { return nil, errors.WithMessage(err, "execute main template") }

    buf, err := format.Source(b.Bytes())
    if err != nil { return nil, errors.WithMessage(err, "format main template") }

    target := fmt.Sprintf("%s.go", filename(pkgPath))
    err = ioutil.WriteFile(target, buf, 0644)
    if err != nil { return nil, errors.WithMessagef(err, "write file %s", target) }
    // ...
}

El comentario original usaba un tryf hipotético para adjuntar el formato, que se eliminó. No está claro cuál es la mejor manera de agregar todos los contextos distintos, y tal vez try ni siquiera sería aplicable.

@cpuguy83
Para mí, es más legible con try . En este ejemplo, leo "abrir un archivo, leer todos los bytes, enviar datos". Con el manejo de errores regular, leería "abrir un archivo, verificar si hubo un error, el manejo de errores hace esto, luego leer todos los bytes, ahora verificar si sucedió algo ..." Sé que puedes escanear a través de err != nil s, pero para mí try es más fácil porque cuando lo veo sé el comportamiento de inmediato: devuelve si err != nil. Si tienes una sucursal, tengo que ver qué hace. Podría hacer cualquier cosa.

También diría que un controlador de error diferido aquí no sería bueno, excepto para envolver el error con un nuevo mensaje

Estoy seguro de que hay otras cosas que puede hacer en el aplazamiento, pero independientemente, try es para el caso general simple de todos modos. Cada vez que quieras hacer algo más, siempre hay un buen manejo de errores de Go. Eso no va a desaparecer.

@zeebo Sí, me gusta eso.
El artículo de @kungfusheep usó una verificación de error de una línea como esa y me emocioné por probarlo. Luego, tan pronto como guardé, gofmt lo expandió en tres líneas, lo cual fue triste. Muchas funciones en stdlib se definen en una línea como esa, por lo que me sorprendió que gofmt lo expandiera.

@qrpnxz

Sucede que leo mucho código go. Una de las mejores cosas del lenguaje es la facilidad que brinda la mayoría de los códigos que siguen un estilo particular (gracias gofmt).
No quiero leer un montón de código envuelto en try(f()) .
Esto significa que habrá una divergencia en el estilo/práctica del código, o linters como "oh, deberías haber usado try() aquí" (que de nuevo ni siquiera me gusta, que es el punto de que yo y otros comentemos sobre esta propuesta).

No es objetivamente mejor que if err != nil { return err } , solo menos para escribir.

Una última cosa:

Si lees la propuesta verás que nada te impide

¿Podemos por favor abstenernos de ese lenguaje? Por supuesto que leí la propuesta. Da la casualidad de que lo leí anoche y luego comenté esta mañana después de pensarlo y no expliqué las minucias de lo que pretendía.
Este es un tono increíblemente contradictorio.

@cpuguy83
Mi chico malo de la CPU. No lo dije de esa manera.

Y supongo que debes señalar que el código que usa try se verá bastante diferente del código que no lo usa, así que puedo imaginar que eso afectaría la experiencia de analizar ese código, pero no puedo estar totalmente de acuerdo con esa diferencia. significa peor en este caso, aunque entiendo que a usted personalmente no le gusta como a mí personalmente me gusta. Muchas cosas en Go son así. En cuanto a lo que los linters te digan que hagas es otra cuestión completamente diferente, creo.

Seguro que no es objetivamente mejor. Estaba expresando que era más legible de esa manera para mí . Cuidadosamente redacté eso.

Una vez más, lo siento por sonar de esa manera. Aunque este es un argumento, no fue mi intención enemistarme contigo.

https://github.com/golang/go/issues/32437#issuecomment-498908380

Nadie te obligará a probar.

Ignorando la ligereza, creo que es una forma bastante tonta de descartar una crítica de diseño.

Claro, no tengo que usarlo. Pero cualquiera con quien escriba el código podría usarlo y obligarme a tratar de descifrar try(try(try(to()).parse().this)).easily()) . es como decir

Nadie te obligará a usar la interfaz vacía{}.

De todos modos, Go es bastante estricto con la simplicidad: gofmt hace que todo el código tenga el mismo aspecto. El camino feliz se mantiene a la izquierda y todo lo que puede resultar costoso o sorprendente es explícito . try como se propone es un giro de 180 grados de esto. Simplicidad != conciso.

Como mínimo try debería ser una palabra clave con lvalues.

No es _objetivamente_ mejor que if err != nil { return err } , solo menos para escribir.

Hay una diferencia objetiva entre los dos: try(Foo()) es una expresión. Para algunos, esa diferencia es una desventaja (la crítica try(strconv.Atoi(x))+try(strconv.Atoi(y)) ). Para otros, esa diferencia es una ventaja por la misma razón. Todavía no es objetivamente mejor o peor, pero tampoco creo que la diferencia deba esconderse debajo de la alfombra y afirmar que es "solo menos para escribir" no le hace justicia a la propuesta.

@elagergren-spideroak es difícil decir que try es molesto de ver en un respiro y luego decir que no es explícito en el siguiente. Tienes que elegir uno.

es común ver que los argumentos de función se colocan primero en variables temporales. Estoy seguro de que sería más común ver

this := try(to()).parse().this
that := try(this.easily())

que tu ejemplo.

try no hacer nada es el camino feliz, por lo que se ve como se esperaba. En el camino infeliz lo único que hace es volver. Ver que hay un try es suficiente para recopilar esa información. Tampoco hay nada costoso en regresar de una función, por lo que, según esa descripción, no creo que try esté haciendo un 180

@josharian Con respecto a su comentario en https://github.com/golang/go/issues/32437#issuecomment -498941854, no creo que haya un error de evaluación inicial aquí.

diferir fmt.HandleErrorf(&err, “foobar: %v”, err)

El valor no modificado de err se pasa a HandleErrorf y se pasa un puntero a err . Verificamos si err es nil (usando el puntero). Si no, formateamos la cadena, usando el valor no modificado de err . Luego establecemos err en el valor de error formateado, usando el puntero.

@Merovius Sin embargo, la propuesta realmente es solo una macro de azúcar de sintaxis, por lo que terminará siendo sobre lo que la gente piensa que se ve mejor o que causará menos problemas. Si crees que no, por favor explícamelo. Por eso estoy a favor, personalmente. Es una buena adición sin agregar palabras clave desde mi perspectiva.

@ianlancetaylor , creo que @josharian tiene razón: el valor "no modificado" de err es el valor en el momento en que defer se coloca en la pila, no el valor (presuntamente previsto) de err establecido por try antes de regresar.

El otro problema que tengo con try es que hace que sea mucho más fácil para las personas volcar más y lógica en una sola línea. Este es mi principal problema con la mayoría de los otros idiomas, es que hacen que sea muy fácil poner como 5 expresiones en una sola línea, y no quiero que eso pase.

this := try(to()).parse().this
that := try(this.easily())

^^ incluso esto es francamente horrible. La primera línea, tengo que saltar de un lado a otro haciendo coincidir los padres en mi cabeza. Incluso la segunda línea, que en realidad es bastante simple... es realmente difícil de leer.
Las funciones anidadas son difíciles de leer.

parser, err := to()
if err != nil {
    return err
}
this := parser.parse().this
that, err := this.easily()
if err != nil {
    return err
}

^^ Esto es mucho más fácil y mejor en mi opinión. Es súper simple y claro. sí, son muchas más líneas de código, no me importa. Es muy obvio.

@bcmills @josharian Ah, por supuesto, gracias. Entonces tendría que ser

defer func() { fmt.HandleErrorf(&err, “foobar: %v”, err) }()

No tan agradable Tal vez fmt.HandleErrorf debería pasar implícitamente el valor del error como el último argumento después de todo.

Este problema ha recibido muchos comentarios muy rápidamente, y me parece que muchos de ellos repiten comentarios que ya se han hecho. Por supuesto, siéntase libre de comentar, pero me gustaría sugerir amablemente que si desea reiterar un punto que ya se ha planteado, lo haga utilizando los emojis de GitHub, en lugar de repetir el punto. Gracias.

@ianlancetaylor si fmt.HandleErrorf envía err como el primer argumento después del formato, entonces la implementación será mejor y el usuario podrá hacer referencia a ella mediante %[1]v siempre.

@natefinch Absolutamente de acuerdo.

Me pregunto si un enfoque de estilo oxidado sería más aceptable.
Tenga en cuenta que esta no es una propuesta solo pensando en ella ...

this := to()?.parse().this
that := this.easily()?

Al final, creo que esto es mejor, pero (podría usar un ! o algo más también...), pero aún así no soluciona bien el problema del manejo de errores.

por supuesto, rust también tiene try() más o menos así, pero... el otro estilo rust.

No es _objetivamente_ mejor que if err != nil { return err } , solo menos para escribir.

Hay una diferencia objetiva entre los dos: try(Foo()) es una expresión. Para algunos, esa diferencia es una desventaja (la crítica try(strconv.Atoi(x))+try(strconv.Atoi(y)) ). Para otros, esa diferencia es una ventaja por la misma razón. Todavía no es objetivamente mejor o peor, pero tampoco creo que la diferencia deba esconderse debajo de la alfombra y afirmar que es "solo menos para escribir" no le hace justicia a la propuesta.

Esta es una de las principales razones por las que me gusta esta sintaxis; me permite usar una función de devolución de errores como parte de una expresión más grande sin tener que nombrar todos los resultados intermedios. En algunas situaciones, nombrarlos es fácil, pero en otras no hay un nombre particularmente significativo o no redundante para darles, en cuyo caso prefiero no darles ningún nombre.

@MrTravisB

Exactamente mi punto. Esta propuesta intenta resolver un caso de uso singular en lugar de proporcionar una herramienta para resolver el problema más amplio del manejo de errores. Creo que la pregunta fundamental es exactamente lo que usted señaló.

¿Qué dije específicamente que es exactamente tu punto? Más bien me parece que básicamente malinterpretaste mi punto si crees que estamos de acuerdo.

En mi opinión y experiencia, este caso de uso es una pequeña minoría y no garantiza una sintaxis abreviada.

En la fuente de Go hay miles de casos que podrían ser manejados por try listos para usar, incluso si no hubiera forma de agregar contexto a los errores. Si es menor, sigue siendo una causa común de queja.

Además, el enfoque de usar aplazar para manejar errores tiene problemas en el sentido de que asume que desea manejar todos los errores posibles de la misma manera. las declaraciones diferidas no se pueden cancelar.

De manera similar, el enfoque de usar + para manejar la aritmética asume que no desea restar, por lo que no lo hace si no lo hace. La pregunta interesante es si el contexto de error de todo el bloque representa al menos un patrón común.

¿Qué pasa si quiero un manejo de errores diferente para los errores que pueden ser devueltos por foo() frente a foo2()?

Nuevamente, entonces no usa try . Entonces no ganas nada con try , pero tampoco pierdes nada.

@cpuguy83

Me pregunto si un enfoque de estilo oxidado sería más aceptable.

La propuesta presenta un argumento en contra de esto.

En este punto, creo que tener try{}catch{} es más legible :upside_down_face:

1. El uso de importaciones con nombre para dar la vuelta a los casos de esquina defer no solo es horrible para cosas como godoc, sino que, lo que es más importante, es muy propenso a errores. No me importa, puedo envolver todo con otros func() para solucionar el problema, son solo más cosas que debo tener en cuenta, creo que fomenta una "mala práctica".

2. Nadie te obligará a probar.

   Eso no significa que sea una buena solución, estoy señalando que la idea actual tiene una falla en el diseño y pido que se aborde de una manera que sea menos propensa a errores.

3. Creo que ejemplos como try(try(try(to()).parse().this)).easily()) no son realistas, esto ya podría hacerse con otras funciones y creo que sería justo que aquellos que revisan el código pidan que se divida.

4. ¿Qué pasa si tengo 3 lugares que pueden fallar y quiero envolver cada lugar por separado? try() hace que esto sea muy difícil, de hecho, try() ya está desalentando los errores de ajuste dada la dificultad, pero aquí hay un ejemplo de lo que quiero decir:

   func before() error {
     x, err := foo()
     if err != nil {
       wrap(err, "error on foo")
     }
     y, err := bar(x)
     if err != nil {
       wrapf(err, "error on bar with x=%v", x)
     }
     fmt.Println(y)
     return nil
   }
   
   func after() (err error) {
     defer fmt.HandleErrorf(&err, "something failed but I don't know where: %v", err)
     x := try(foo())
     y := try(bar(x))
     fmt.Println(y)
     return nil
   }
   

5. Nuevamente, entonces no usa try . Entonces no ganas nada con try , pero tampoco pierdes nada.

   Digamos que es una buena práctica envolver los errores con un contexto útil, try() se consideraría una mala práctica porque no agrega ningún contexto. Esto significa que try() es una característica que nadie quiere usar y se convierte en una característica que se usa tan raramente que bien podría no haber existido.

   En lugar de simplemente decir "bueno, si no te gusta, no lo uses y cállate" (así es como se lee), creo que sería mejor tratar de abordar lo que muchos de los usuarios consideran una falla. en el diseño. ¿Podemos discutir en cambio qué podría modificarse del diseño propuesto para que nuestra preocupación se maneje de una mejor manera?

@boomlinde El punto en el que estamos de acuerdo es que esta propuesta está tratando de resolver un caso de uso menor y el hecho de que "si no lo necesita, no lo use" es el argumento principal para promover ese punto. Como dijo @elagergren-spideroak, ese argumento no funciona porque incluso si no quiero usarlo, otros lo harán, lo que me obliga a usarlo. Según la lógica de su argumento, Go también debería tener una declaración ternaria. Y si no le gustan las declaraciones ternarias, no las use.

Descargo de responsabilidad: creo que Go debería tener una declaración ternaria, pero dado que el enfoque de Go para las características del lenguaje es no introducir características que podrían hacer que el código sea más difícil de leer de lo que no debería.

Se me ocurre otra cosa: veo muchas críticas basadas en la idea de que tener try podría alentar a los desarrolladores a manejar los errores sin cuidado. Pero en mi opinión, esto es, en todo caso, más cierto en el lenguaje actual; el modelo de manejo de errores es lo suficientemente molesto como para alentar a uno a tragar o ignorar algunos errores para evitarlo. Por ejemplo, he escrito cosas como esta un par de veces:

func exists(filename string) bool {
  _, err := os.Stat(filename)
  return err == nil
}

para poder escribir if exists(...) { ... } , aunque este código ignora silenciosamente algunos posibles errores. Si tuviera try , probablemente no me molestaría en hacer eso y simplemente devolvería (bool, error) .

Siendo caótico aquí, lanzaré la idea de agregar una segunda función integrada llamada catch que recibirá una función que recibe un error y devuelve un error sobrescrito, luego si un catch posterior se llama sobrescribiría el controlador. por ejemplo:

func catch(handler func(err error) error) {
  // .. impl ..
}

Ahora, esta función incorporada también será una función similar a una macro que manejaría el siguiente error que devolverá try esta manera:

func wrapf(format string, ...values interface{}) func(err error) error {
  // user defined
  return func(err error) error {
    return fmt.Errorf(format + ": %v", ...append(values, err))
  }
}
func sample() {
  catch(wrapf("something failed in foo"))
  try(foo()) // "something failed in foo: <error>"
  x := try(foo2()) // "something failed in foo: <error>"
  // Subsequent calls for catch overwrite the handler
  catch(wrapf("something failed in bar with x=%v", x))
  try(bar(x)) // "something failed in bar with x=-1: <error>"
}

Esto es bueno porque puedo envolver errores sin defer que puede ser propenso a errores a menos que usemos valores devueltos con nombre o envolvamos con otra función, también es bueno porque defer agregaría el mismo controlador de errores para todos los errores incluso si quiero manejar 2 de ellos de manera diferente. También puedes usarlo como mejor te parezca, por ejemplo:

func foo(a, b string) (int64, error) {
  return try(strconv.Atoi(a)) + try(strconv.Atoi(b))
}
func withContext(a, b string) (int64, error) {
  catch(func (err error) error {
    return fmt.Errorf("can't parse a: %s, b: %s, err: %v", a, b, err)
  })
  return try(strconv.Atoi(a)) + try(strconv.Atoi(b))
}
func moreExplicitContext(a, b string) (int64, error) {
  catch(func (err error) error {
    return fmt.Errorf("can't parse a: %s, err: %v", a, err)
  })
  x := try(strconv.Atoi(a))
  catch(func (err error) error {
    return fmt.Errorf("can't parse b: %s, err: %v", b, err)
  })
  y := try(strconv.Atoi(b))
  return x + y
}
func withHelperWrapf(a, b string) (int64, error) {
  catch(wrapf("can't parse a: %s", a))
  x := try(strconv.Atoi(a))
  catch(wrapf("can't parse b: %s", b))
  y := try(strconv.Atoi(b))
  return x + y
}
func before(a, b string) (int64, error) {
  x, err := strconv.Atoi(a)
  if err != nil {
    return 0,  fmt.Errorf("can't parse a: %s, err: %v", a, err)
  }
  y, err := strconv.Atoi(b)
  if err != nil {
    return 0,  fmt.Errorf("can't parse b: %s, err: %v", b, err)
  }
  return x + y
}

Y aún en el estado de ánimo caótico (para ayudarlo a empatizar) Si no le gusta catch , no tiene que usarlo.

Ahora... Realmente no lo digo en serio en la última oración, pero parece que no es útil para la discusión, en mi opinión es muy agresivo.
Aún así, si seguimos esta ruta, creo que también podríamos tener try{}catch(error err){} en su lugar :stuck_out_tongue:

Ver también #27519 - el modelo de error #id/catch

Nadie te obligará a probar.

Ignorando la ligereza, creo que es una forma bastante tonta de descartar una crítica de diseño.

Lo siento, simplista no era mi intención.

Lo que estoy tratando de decir es que try no pretende ser una solución al 100%. Hay varios paradigmas de manejo de errores que try no maneja bien. Por ejemplo, si necesita agregar un contexto dependiente del sitio de llamadas al error. Siempre puede volver a usar if err != nil { para manejar esos casos más complicados.

Ciertamente es un argumento válido que try no puede manejar X, para varias instancias de X. Pero a menudo manejar el caso X significa hacer que el mecanismo sea más complicado. Aquí hay una compensación, manejar X por un lado pero complicar el mecanismo para todo lo demás. Lo que hacemos depende de cuán común es X y cuánta complicación requeriría manejar X.

Entonces, con "Nadie te va a obligar a probar", quiero decir que creo que el ejemplo en cuestión está en el 10%, no en el 90%. Esa afirmación ciertamente está sujeta a debate, y estoy feliz de escuchar contraargumentos. Pero eventualmente tendremos que trazar la línea en algún lugar y decir "sí, try no manejará ese caso. Tendrá que usar el manejo de errores al viejo estilo. Lo siento".

No es que "intentar no pueda manejar este caso específico de manejo de errores" ese es el problema, es "intentar lo alienta a no envolver sus errores". La idea check-handle lo obligó a escribir una declaración de devolución, por lo que escribir un ajuste de error fue bastante trivial.

Según esta propuesta, debe usar un retorno con nombre con defer , que no es intuitivo y parece muy complicado.

La idea check-handle lo obligó a escribir una declaración de devolución, por lo que escribir un ajuste de error fue bastante trivial.

Eso no es cierto: en el borrador de diseño, cada función que devuelve un error tiene un controlador predeterminado que simplemente devuelve el error.

Sobre la base del punto travieso de @Goodwine , realmente no necesita funciones separadas como HandleErrorf si tiene una sola función de puente como

func handler(err *error, handle func(error) error) {
  // nil handle is treated as the identity
  if *err != nil && handle != nil {
    *err = handle(*err)
  }
}

que usarías como

defer handler(&err, func(err error) error {
  if errors.Is(err, io.EOF) {
    return nil
  }
  return fmt.Errorf("oops: %w", err)
})

Podría hacer que handler en sí mismo sea un elemento integrado semimágico como try .

Si es mágico, podría tomar implícitamente su primer argumento, lo que permitiría usarlo incluso en funciones que no mencionan su retorno error , eliminando uno de los aspectos menos afortunados de la propuesta actual y haciéndolo menos quisquilloso y propenso a errores para decorar errores. Por supuesto, eso no reduce mucho el ejemplo anterior:

defer handler(func(err error) error {
  if errors.Is(err, io.EOF) {
    return nil
  }
  return fmt.Errorf("oops: %w", err)
})

Si fuera mágico de esta manera, tendría que ser un error de tiempo de compilación si se usara en cualquier lugar excepto como argumento para defer . Podría ir un paso más allá y hacer que diferir implícitamente, pero defer handler se lee bastante bien.

Dado que usa defer , podría llamar a su función handle cada vez que se devolviera un error no nulo, lo que lo hace útil incluso sin try ya que podría agregar un

defer handler(wrapErrWithPackageName)

en la parte superior a fmt.Errorf("mypkg: %w", err) todo.

Eso le da mucho de la antigua propuesta check / handle pero funciona con aplazamiento natural (y explícito) mientras elimina la necesidad, en la mayoría de los casos, de nombrar explícitamente un err retorno. Como try , es una macro relativamente sencilla que (me imagino) podría implementarse por completo en la interfaz.

Eso no es cierto: en el borrador de diseño, cada función que devuelve un error tiene un controlador predeterminado que simplemente devuelve el error.

Mala mía, tienes razón.

Quiero decir que creo que el ejemplo en cuestión está en el 10%, no en el 90%. Esa afirmación ciertamente está sujeta a debate, y estoy feliz de escuchar contraargumentos. Pero eventualmente tendremos que trazar la línea en algún lugar y decir "sí, intentar no manejará ese caso. Tendrá que usar el manejo de errores al viejo estilo. Lo siento".

De acuerdo, mi opinión es que esta línea debe dibujarse al verificar EOF o similar, no al envolver. Pero tal vez si los errores tuvieran más contexto, esto ya no sería un problema.

¿Podría try() corregir automáticamente los errores con un contexto útil para la depuración? Por ejemplo, si xerrors se convierte en errors , los errores deberían tener algo parecido a un seguimiento de pila que try() podría agregar, ¿no? Si es así, tal vez eso sería suficiente 🤔

Si los objetivos son (leer https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md):

• eliminar el repetitivo
• cambios mínimos de idioma
• cubriendo los "escenarios más comunes"
• agregando muy poca complejidad al lenguaje

Tomaría la sugerencia de darle un ángulo y permitir la migración de código de "pequeños pasos" para todos los miles de millones de líneas de código que existen.

en lugar de lo sugerido:

func printSum(a, b string) error {
        defer fmt.HandleErrorf(&err, "sum %s %s: %v", a,b, err) 
        x := try(strconv.Atoi(a))
        y := try(strconv.Atoi(b))
        fmt.Println("result:", x + y)
        return nil
}

Podemos:

func printSum(a, b string) error {
        var err ErrHandler{HandleFunc : twoStringsErr("printSum",a,b)} 
        x, err.Error := strconv.Atoi(a)
        y,err.Error := strconv.Atoi(b)
        fmt.Println("result:", x + y)
        return nil
}

¿Qué ganaríamos?
twoStringsErr se puede incorporar a printSum, o un controlador general que sabe cómo capturar errores (en este caso con 2 parámetros de cadena), por lo que si tengo las mismas firmas de funciones repetidas utilizadas en muchas de mis funciones, no necesito reescribir el controlador cada una hora
De la misma manera, puedo extender el tipo ErrHandler de la siguiente manera:

type ioErrHandler ErrHandler
func (i ErrHandler) Handle() ...{

}

o

type parseErrHandler ErrHandler
func (p parseErrHandler) Handle() ...{

}

o

type str2IntErrHandler ErrHandler
func (s str2IntErrHandler) Handle() ...{

}

y usa esto en todo mi código:

func printSum(a, b string) error {
        var pErr str2IntErrHandler 
        x, err.Error := strconv.Atoi(a)
        y,err.Error := strconv.Atoi(b)
        fmt.Println("result:", x + y)
        return nil
}

Por lo tanto, la necesidad real sería desarrollar un disparador cuando err.Error se establece en no nulo
Usando este método también podemos:

func (s str2IntErrHandler) Handle() bool{
   **return false**
}

Lo que le diría a la función de llamada que continúe en lugar de regresar

Y use diferentes controladores de errores en la misma función:

func printSum(a, b string) error {
        var pErr str2IntErrHandler 
        var oErr overflowError 
        x, err.Error := strconv.Atoi(a)
        y,err.Error := strconv.Atoi(b)
        fmt.Println("result:", x + y)
        totalAsByte,oErr := sumBytes(x,y)
        sunAsByte,oErr := subtractBytes(x,y)
        return nil
}

etc

Repasando los goles otra vez

• eliminar el repetitivo - hecho
• cambios mínimos de idioma - hecho
• cubriendo los "escenarios más comunes" - más que la OMI sugerida
• agregando muy poca complejidad al lenguaje - sone
  Además: migración de código más sencilla desde

x, err := strconv.Atoi(a)

para

x, err.Error := strconv.Atoi(a)

y, de hecho, mejor legibilidad (en mi opinión, de nuevo)

@guybrand eres el último adherente a este tema recurrente (que me gusta).

Consulte https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -themes

@guybrand Eso parece una propuesta completamente diferente; Creo que deberías archivarlo como un problema propio para que este pueda centrarse en discutir la propuesta de @griesemer .

@natefinch está de acuerdo. Creo que esto está más orientado a mejorar la experiencia al escribir Go en lugar de optimizar para la lectura. Me pregunto si las macros o fragmentos de IDE podrían resolver el problema sin que esto se convierta en una característica del lenguaje.

@Buen vino

Digamos que es una buena práctica envolver los errores con un contexto útil, try() se consideraría una mala práctica porque no agrega ningún contexto. Esto significa que try() es una característica que nadie quiere usar y se convierte en una característica que se usa tan raramente que bien podría no haber existido.

Como se indica en la propuesta (y se muestra en el ejemplo), try no impide fundamentalmente que agregue contexto. Diría que la forma en que se propone, agregar contexto a los errores, es completamente ortogonal. Esto se aborda específicamente en las preguntas frecuentes de la propuesta.

Reconozco que try no será útil dentro de una sola función si hay una multitud de contextos diferentes que desea agregar a diferentes errores de llamadas a funciones. Sin embargo, también creo que algo en la vena general de HandleErrorf cubre una gran área de uso porque no es inusual agregar solo el contexto de toda la función a los errores.

En lugar de simplemente decir "bueno, si no te gusta, no lo uses y cállate" (así es como se lee), creo que sería mejor tratar de abordar lo que muchos de los usuarios consideran una falla. en el diseño.

Si es así como se lee, pido disculpas. Mi punto no es que debas fingir que no existe si no te gusta. Es que es obvio que hay casos en los que try serían inútiles y que no deberías usarlo en esos casos, lo que para esta propuesta creo que logra un buen equilibrio entre KISS y la utilidad general. No pensé que no estaba claro en ese punto.

Gracias a todos por los prolíficos comentarios hasta ahora; esto es muy informativo.
Aquí está mi intento de un resumen inicial, para tener una mejor idea de los comentarios. Disculpas de antemano por cualquier persona que haya perdido o tergiversado; Espero haber entendido bien la esencia general.

0) En el lado positivo, @rasky , @adg , @eandre , @dpinela y otros expresaron explícitamente su felicidad por la simplificación del código que proporciona try .

1) La preocupación más importante parece ser que try no fomenta un buen estilo de manejo de errores, sino que promueve la "salida rápida". ( @agnivade , @peterbourgon , @politician , @a8m , @eandre , @prologic , @kungfusheep , @cpuguy y otros han expresado su preocupación por esto).

2) A muchas personas no les gusta la idea de una función integrada o la sintaxis de la función que viene con ella porque oculta un return . Sería mejor utilizar una palabra clave. ( @sheerun , @Redundancy , @dolmen , @komuw , @RobertGrantEllis , @elagergren-spideroak). try también puede pasarse por alto fácilmente (@peterbourgon), especialmente porque puede aparecer en expresiones que pueden anidarse arbitrariamente. A @natefinch le preocupa que try haga que sea "demasiado fácil volcar demasiado en una línea", algo que generalmente tratamos de evitar en Go. Además, la compatibilidad con IDE para enfatizar try puede no ser suficiente (@dominikh); try necesita "sostenerse por sí mismo".

3) Para algunos, el status quo de declaraciones explícitas de if no es un problema, están contentos con eso ( @bitfield , @marwan-at-work, @natefinch). Es mejor tener una sola forma de hacer las cosas (@gbbr); y las declaraciones if explícitas son mejores que las return implícitas ( @DavexPro , @hmage , @prologic , @natefinch).
Del mismo modo, a @mattn le preocupa el "enlace implícito" del resultado del error a try : la conexión no es explícitamente visible en el código.

4) El uso try hará que sea más difícil depurar el código; por ejemplo, puede ser necesario volver a escribir una expresión try en una declaración if solo para que se puedan insertar declaraciones de depuración ( @deanveloper , @typeless , @networkimprov , otros).

5) Existe cierta preocupación sobre el uso de devoluciones con nombre ( @buchanae , @adg).

Varias personas han brindado sugerencias para mejorar o modificar la propuesta:

6) Algunos han retomado la idea de un controlador de errores opcional (@beoran) o una cadena de formato proporcionada a try ( @unexge , @a8m , @eandre , @gotwarlost) para fomentar un buen manejo de errores.

7) @pierrec sugirió que gofmt podría formatear adecuadamente las expresiones try para hacerlas más visibles.
Alternativamente, se podría hacer que el código existente sea más compacto al permitir que gofmt formatee declaraciones if para verificar si hay errores en una línea (@zeebo).

8) @marwan-at-work argumenta que try simplemente cambia el manejo de errores de if declaraciones a try expresiones. En cambio, si realmente queremos resolver el problema, Go debería "poseer" el manejo de errores haciéndolo verdaderamente implícito. El objetivo debería ser hacer que el manejo (adecuado) de errores sea más simple y que los desarrolladores sean más productivos (@cpuguy).

9) Finalmente, a algunas personas no les gusta el nombre try ( @beoran , @HiImJC , @dolmen) o preferirían un símbolo como ? ( @twisted1919 , @leaxoy , otros) .

Algunos comentarios sobre esta retroalimentación (numerados en consecuencia):

0) ¡Gracias por los comentarios positivos! :-)

1) Sería bueno aprender más sobre esta preocupación. El estilo de codificación actual que usa declaraciones if para probar errores es tan explícito como puede ser. Es muy fácil agregar información adicional a un error, de forma individual (para cada if ). A menudo tiene sentido manejar todos los errores detectados en una función de manera uniforme, lo que se puede hacer con defer ; esto ya es posible ahora. Es el hecho de que ya tenemos todas las herramientas para un buen manejo de errores en el lenguaje, y el problema de una construcción de controlador que no es ortogonal a defer , lo que nos llevó a dejar de lado un nuevo mecanismo únicamente para aumentar los errores. .

2) Por supuesto, existe la posibilidad de utilizar una palabra clave o una sintaxis especial en lugar de una incorporada. Una nueva palabra clave no será compatible con versiones anteriores. Un nuevo operador podría, pero parece incluso menos visible. La propuesta detallada analiza los diversos pros y contras en detalle. Pero tal vez estemos juzgando mal esto.

3) El motivo de esta propuesta es que la gestión de errores (específicamente el código repetitivo asociado) se mencionó como un problema importante en Go (junto a la falta de genéricos) por parte de la comunidad de Go. Esta propuesta aborda directamente la preocupación repetitiva. No hace más que resolver el caso más básico porque cualquier caso más complejo se maneja mejor con lo que ya tenemos. Entonces, aunque un buen número de personas están contentas con el statu quo, hay un contingente (probablemente) igualmente grande de personas a las que les encantaría un enfoque más simplificado como try , sabiendo que esto es "simplemente" azúcar sintáctica.

4) El punto de depuración es una preocupación válida. Si es necesario agregar código entre la detección de un error y un return , tener que reescribir una expresión try en una instrucción if podría ser molesto.

5) Valores devueltos con nombre: el documento detallado analiza esto en detalle. Si esta es la principal preocupación sobre esta propuesta, creo que estamos en un buen lugar.

6) Argumento de controlador opcional para try : el documento detallado también analiza esto. Consulte la sección sobre iteraciones de diseño.

7) Usar gofmt para dar formato a las expresiones try modo que sean más visibles sería una opción. Pero quitaría algunos de los beneficios de try cuando se usa en una expresión.

8) Hemos considerado ver el problema desde el punto de vista del manejo de errores ( handle ) en lugar de desde el punto de vista de la prueba de errores ( try ). Específicamente, consideramos brevemente solo introducir la noción de un controlador de errores (similar al borrador de diseño original presentado en el Gophercon del año pasado). La idea era que si (y solo si) se declara un controlador, en asignaciones de valores múltiples donde el último valor es del tipo error , ese valor simplemente puede dejarse de lado en una asignación. El compilador verificaría implícitamente si no es nulo y, de ser así, se ramificaría al controlador. Eso haría que el manejo explícito de errores desapareciera por completo y alentaría a todos a escribir un controlador en su lugar. Esto parecía un enfoque extremo porque sería completamente implícito: el hecho de que ocurra un control sería invisible.

9) ¿Puedo sugerir que no nos deshagamos del nombre en este punto? Una vez que se resuelvan todas las demás preocupaciones, es un mejor momento para afinar el nombre.

Esto no quiere decir que las preocupaciones no sean válidas: las respuestas anteriores simplemente indican nuestro pensamiento actual. En el futuro, sería bueno comentar sobre nuevas inquietudes (o nueva evidencia que respalde estas inquietudes); solo reiterar lo que ya se ha dicho no nos brinda más información.

Y finalmente, parece que no todos los que comentan sobre el tema han leído el documento detallado. Por favor, hágalo antes de comentar para evitar repetir lo que ya se ha dicho. Gracias.

Este no es un comentario sobre la propuesta, sino un informe de error tipográfico. No se solucionó desde que se publicó la propuesta completa, así que pensé en mencionarlo:

func try(t1 T1, t1 T2, … tn Tn, te error) (T1, T2, … Tn)

debiera ser:

func try(t1 T1, t2 T2, … tn Tn, te error) (T1, T2, … Tn)

¿Valdría la pena analizar el código Go disponible abiertamente para las declaraciones de verificación de errores para tratar de averiguar si la mayoría de las verificaciones de errores son realmente repetitivas o si, en la mayoría de los casos, varias verificaciones dentro de la misma función agregan información contextual diferente? La propuesta tendría mucho sentido para el primer caso, pero no ayudaría al segundo. En el último caso, las personas continuarán usando if err != nil o dejarán de agregar contexto adicional, usarán try() y recurrirán a agregar contexto de error común por función que, en mi opinión, sería dañino. Con las próximas funciones de valores de error, creo que esperamos que las personas envuelvan los errores con más información con más frecuencia. Probablemente entendí mal la propuesta, pero AFAIU, esto ayuda a reducir el modelo solo cuando todos los errores de una sola función deben envolverse exactamente de una manera y no ayuda si una función trata con cinco errores que podrían necesitar envolverse de manera diferente. No estoy seguro de qué tan comunes son estos casos en la naturaleza (bastante comunes en la mayoría de mis proyectos), pero me preocupa que try() pueda alentar a las personas a usar envoltorios comunes por función, incluso cuando tendría sentido envolver diferentes errores. diferentemente.

Solo un comentario rápido respaldado con datos de un pequeño conjunto de muestra:

Proponemos una nueva función integrada llamada try, diseñada específicamente para eliminar las declaraciones repetitivas if típicamente asociadas con el manejo de errores en Go.

Si este es el problema central que se resuelve con esta propuesta, encuentro que este "repetitivo" solo representa ~ 1.4% de mi código en docenas de proyectos de código abierto disponibles públicamente por un total de ~ 60k SLOC.

¿Curioso si alguien más tiene estadísticas similares?

En una base de código mucho más grande como Go, con un total de alrededor de ~ 1,6 millones de SLOC, esto equivale a aproximadamente ~ 0,5% de la base de código con líneas como if err != nil .

¿Es este realmente el problema más impactante para resolver con Go 2?

Muchas gracias @griesemer por tomarse el tiempo de revisar las ideas de todos y proporcionar pensamientos de forma explícita. Creo que realmente ayuda con la percepción de que la comunidad está siendo escuchada en el proceso.

1. @pierrec sugirió que gofmt podría formatear expresiones de prueba adecuadamente para hacerlas más visibles.
   Alternativamente, se podría hacer que el código existente sea más compacto al permitir que gofmt formatee declaraciones if que verifiquen errores en una línea (@zeebo).

1. Usar gofmt para dar formato a las expresiones try modo que sean más visibles sería sin duda una opción. Pero quitaría algunos de los beneficios de try cuando se usa en una expresión.

Estos son pensamientos valiosos acerca de requerir gofmt para formatear try , pero estoy interesado si hay algún pensamiento en particular sobre gofmt que permita la verificación de declaraciones if el error de ser una línea. La propuesta se agrupó con el formato de try , pero creo que es algo completamente ortogonal. Gracias.

@griesemer gracias por el increíble trabajo de revisar todos los comentarios y responder a la mayoría, si no a todos, los comentarios 🎉

Una cosa que no se abordó en sus comentarios fue la idea de usar la parte de herramientas/examen del lenguaje Go para mejorar la experiencia de manejo de errores, en lugar de actualizar la sintaxis de Go.

Por ejemplo, con el aterrizaje del nuevo LSP ( gopls ), parece un lugar perfecto para analizar la firma de una función y ocuparse del manejo de errores repetitivo para el desarrollador, con el envoltorio y la verificación adecuados también.

@griesemer Estoy seguro de que esto no está bien pensado, pero traté de modificar su sugerencia más cerca de algo con lo que me sentiría cómodo aquí: https://www.reddit.com/r/golang/comments/bwvyhe /proposal_a_builtin_go_error_check_function_try/eq22bqa?utm_source=share&utm_medium=web2x

@zeebo Sería fácil hacer que el formato $ gofmt sea if err != nil { return ...., err } en una sola línea. Presumiblemente, solo sería para este tipo específico de patrón if , no para todas las declaraciones "cortas" if .

Del mismo modo, existía la preocupación de que try fuera invisible porque está en la misma línea que la lógica empresarial. Tenemos todas estas opciones:

Estilo actual:

a, b, c, ... err := BusinessLogic(...)
if err != nil {
   return ..., err
}

Una línea if :

a, b, c, ... err := BusinessLogic(...)
if err != nil { return ..., err }

try en una línea separada (!):

a, b, c, ... err := BusinessLogic(...)
try(err)

try según lo propuesto:

a, b, c := try(BusinessLogic(...))

La primera y la última línea parecen las más claras (para mí), especialmente una vez que se usa para reconocer try como lo que es. Con la última línea, se verifica explícitamente un error, pero dado que (generalmente) no es la acción principal, está un poco más en segundo plano.

@marwan-at-work No estoy seguro de lo que está proponiendo que las herramientas hagan por usted. ¿Sugieres que oculten el manejo de errores de alguna manera?

@dpinela

@guybrand Eso parece una propuesta completamente diferente; Creo que deberías archivarlo como un problema propio para que este pueda centrarse en discutir la propuesta de @griesemer .

En mi opinión, mi propuesta difiere solo en la sintaxis, lo que significa:

• Los objetivos son similares en contenido y prioridad.
• La idea de capturar cada error dentro de su propia línea y, en consecuencia (si no es nulo), salir de la función mientras se pasa a través de una función de controlador es similar (pseudo asm: es un "jnz" y una "llamada").
• Esto incluso significa que la cantidad de líneas en el cuerpo de una función (sin el aplazamiento) y el flujo se verían exactamente iguales (y, en consecuencia, AST probablemente también resultaría igual)

por lo que la diferencia principal es si estamos envolviendo la llamada de función original con try(func()) que siempre analizaría la última variable para jnz la llamada o usaría el valor de retorno real para hacer eso.

Sé que parece diferente, pero en realidad es muy similar en concepto.
Por otro lado, si realiza el intento habitual ... captura en muchos lenguajes similares a c, sería una implementación muy diferente, una legibilidad diferente, etc.

Sin embargo, pienso seriamente en escribir una propuesta, gracias por la idea.

@griesemer

No estoy seguro de lo que está proponiendo que las herramientas hagan por usted. ¿Sugieres que oculten el manejo de errores de alguna manera?

Todo lo contrario: estoy sugiriendo que gopls puede opcionalmente escribir el error de manejo repetitivo para usted.

Como mencionaste en tu último comentario:

El motivo de esta propuesta es que la gestión de errores (específicamente el código repetitivo asociado) se mencionó como un problema importante en Go (junto con la falta de genéricos) por parte de la comunidad de Go.

Entonces, el corazón del problema es que el programador termina escribiendo una gran cantidad de código repetitivo. Así que el problema es sobre escribir, no sobre leer. Por lo tanto, mi sugerencia es: deje que la computadora (herramientas/gopls) haga la escritura para el programador analizando la firma de la función y colocando las cláusulas de manejo de errores adecuadas.

Por ejemplo:

// user begins to write this function: 
func openFile(path string) ([]byte, error) {
  file, err := os.Open(path)
  defer file.Close()
  bts, err := ioutil.ReadAll(file)
  return bts, nil
}

Luego, el usuario activa la herramienta, tal vez simplemente guardando el archivo (similar a cómo funciona normalmente gofmt/goimports) y gopls miraría esta función, analizaría su firma de retorno y aumentaría el código para que sea esto:

// user has triggered the tool (by saving the file, or code action)
func openFile(path string) ([]byte, error) {
  file, err := os.Open(path)
  if err != nil {
    return nil, fmt.Errorf("openFile: %w", err)
  }
  defer file.Close()
  bts, err := ioutil.ReadAll(file)
  if err != nil {
    return nil, fmt.Errorf("openFile: %w", err)
  }
  return bts, nil
}

De esta manera, obtenemos lo mejor de ambos mundos: obtenemos la legibilidad/explicidad del sistema de manejo de errores actual, y el programador no escribió ningún texto estándar de manejo de errores. Aún mejor, el usuario puede seguir adelante y modificar los bloques de manejo de errores más adelante para tener un comportamiento diferente: gopls puede entender que el bloque existe y no lo modificaría.

¿Cómo sabría la herramienta que tenía la intención de manejar el err más adelante en la función en lugar de regresar antes? Aunque es raro, pero el código que he escrito no obstante.

Pido disculpas si esto se ha mencionado antes, pero no pude encontrar ninguna mención al respecto.

try(DoSomething()) me parece bien y tiene sentido: el código está tratando de hacer algo. try(err) , OTOH, se siente un poco fuera de lugar, semánticamente hablando: ¿cómo se intenta un error? En mi opinión, uno podría _probar_ o _verificar_ un error, pero _intentarlo_ no me parece correcto.

Me doy cuenta de que permitir try(err) es importante por razones de consistencia: supongo que sería extraño si try(DoSomething()) funcionara, pero err := DoSomething(); try(err) no. Aún así, parece que try(err) se ve un poco extraño en la página. No se me ocurre ninguna otra función integrada que se pueda hacer para que se vea tan extraña tan fácilmente.

No tengo sugerencias concretas al respecto, pero sin embargo quería hacer esta observación.

@griesemer Gracias. De hecho, la propuesta era solo para return , pero sospecho que sería bueno permitir que cualquier declaración individual sea una sola línea. Por ejemplo, en una prueba uno podría, sin cambios en la biblioteca de prueba, tener

if err != nil { t.Fatal(err) }

La primera y la última línea parecen las más claras (para mí), especialmente una vez que uno se acostumbra a reconocer try como lo que es. Con la última línea, se verifica explícitamente un error, pero dado que (generalmente) no es la acción principal, está un poco más en segundo plano.

Con la última línea, se oculta parte del costo. Si desea anotar el error, que creo que la comunidad ha dicho verbalmente que es la mejor práctica deseada y debe alentarse, habría que cambiar la firma de la función para nombrar los argumentos y esperar que se aplique un solo defer a cada salida en el cuerpo de la función, de lo contrario try no tiene valor; tal vez incluso negativo debido a su facilidad.

No tengo nada más que añadir que creo que no se haya dicho ya.

No vi cómo responder a esta pregunta del documento de diseño. Qué hace este código:

func foo() (err error) {
    src := try(getReader())
    if src != nil {
        n, err := src.Read(nil)
        if err == io.EOF {
            return nil
        }
        try(err)
        println(n)
    }
    return nil
}

Mi entendimiento es que se desazúcar en

func foo() (err error) {
    tsrc, te := getReader()
    if err != nil {
        err = te
        return
    }
    src := tsrc

    if src != nil {
        n, err := src.Read(nil)
        if err == io.EOF {
            return nil
        }

        terr := err
        if terr != nil {
            err = terr
            return
        }

        println(n)
    }
    return nil
}

que falla al compilar porque err se sombrea durante un retorno desnudo. ¿Esto no compilaría? Si es así, es una falla muy sutil y no parece muy improbable que suceda. Si no, entonces está pasando algo más que un poco de azúcar.

@marwan-en-el-trabajo

Como mencionaste en tu último comentario:

El motivo de esta propuesta es que la gestión de errores (específicamente el código repetitivo asociado) se mencionó como un problema importante en Go (junto con la falta de genéricos) por parte de la comunidad de Go.

Entonces, el corazón del problema es que el programador termina escribiendo una gran cantidad de código repetitivo. Así que el problema es sobre escribir, no sobre leer.

Creo que en realidad es al revés: para mí, la mayor molestia con el modelo de manejo de errores actual no es tanto tener que escribirlo, sino más bien cómo dispersa el camino feliz de la función verticalmente en la pantalla, lo que lo hace más difícil de entender en un vistazo. El efecto es particularmente pronunciado en el código de E/S pesado, donde generalmente hay un bloque de repetitivo entre cada dos operaciones. Incluso una versión simplista de CopyFile requiere ~20 líneas, aunque en realidad solo realiza cinco pasos: fuente abierta, fuente cerrada aplazada, destino abierto, fuente copiada -> destino, destino cerrado.

Otro problema con la sintaxis actual es que, como señalé anteriormente, si tiene una cadena de operaciones, cada una de las cuales puede devolver un error, la sintaxis actual lo obliga a dar nombres a todos los resultados intermedios, incluso si prefiere dejar algunos anónimos. Cuando esto sucede, también perjudica la legibilidad porque tienes que pasar ciclos cerebrales analizando esos nombres, aunque no son muy informativos.

Me gusta try en una línea separada.
Y espero que pueda especificar la función handler forma independiente.

func try(error, optional func(error)error)

func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    try(err)

    handle := func(err error) error {
        tx.Rollback()
        return err
    }

    var res int64
    _, err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    try(err, handle)

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    try(err, handle)

    return tx.Commit()
}

@zeebo : Los ejemplos que di son traducciones 1:1. El primero (tradicional if ) no manejó el error, al igual que los demás. Si el primero manejó el error, y si este fuera el único lugar donde se verifica un error en una función, el primer ejemplo (usando un if ) podría ser la opción adecuada para escribir el código. Si hay varias verificaciones de errores, todas las cuales usan el mismo manejo de errores (envoltura), digamos porque todos agregan información sobre la función actual, se podría usar una instrucción defer para manejar todos los errores en un solo lugar. Opcionalmente, uno podría reescribir los if en try (o dejarlos en paz). Si hay varios errores para verificar, y todos manejan los errores de manera diferente (lo que podría ser una señal de que la preocupación de la función es demasiado amplia y es posible que deba dividirse), usar if 's es el camino a seguir. Sí, hay más de una forma de hacer lo mismo, y la elección correcta depende tanto del código como del gusto personal. Si bien nos esforzamos en Go por "una forma de hacer una cosa", por supuesto, este ya no es el caso, especialmente para las construcciones comunes. Por ejemplo, cuando una secuencia if - else - if se vuelve demasiado larga, a veces una switch puede ser más apropiada. A veces, una declaración de variable var x int expresa la intención mejor que x := 0 , y así sucesivamente (aunque no todo el mundo está contento con esto).

Con respecto a su pregunta sobre la "reescritura": No, no habría un error de compilación. Tenga en cuenta que la reescritura ocurre internamente (y puede ser más eficiente de lo que sugiere el patrón de código), y no es necesario que el compilador se queje de un retorno sombreado. En su ejemplo, declaró una variable local err en un ámbito anidado. try aún tendría acceso directo a la variable resultado err , por supuesto. La reescritura podría verse más así debajo de las sábanas.

[editado] PD: una mejor respuesta sería: try no es un retorno desnudo (aunque la reescritura lo parezca). Después de todo, uno da explícitamente try un argumento que contiene (o es) el error que se devuelve si no es nil . El error de sombra para los retornos desnudos es un error en la fuente (no en la traducción subyacente de la fuente. El compilador no necesita el error.

Si el tipo de retorno final de la función general no es de tipo error, ¿podemos entrar en pánico?

Hará que el incorporado sea más versátil (como satisfacer mi preocupación en #32219)

@pjebs Esto ha sido considerado y decidido en contra. Lea el documento de diseño detallado (que se refiere explícitamente a su problema sobre este tema).

También quiero señalar que try() se trata como una expresión aunque funciona como declaración de retorno. Sí, sé que try es una macro incorporada, pero supongo que la mayoría de los usuarios usarán esto como programación funcional.

func doSomething() (error, error, error, error, error) {
   ...
}

try(try(try(try(try(doSomething)))))

El diseño dice que exploraste usando panic en lugar de regresar con el error.

Estoy destacando una sutil diferencia:

Haga exactamente lo que establece su propuesta actual, excepto eliminar la restricción de que la función general debe tener un tipo de retorno final de tipo error .

Si no tiene un tipo de retorno final de error => pánico
Si usa try para declaraciones de variables a nivel de paquete => panic (elimina la necesidad de la convención MustXXX( ) )

Para las pruebas unitarias, un modesto cambio de idioma.

@mattn , dudo mucho que un número significativo de personas escriba un código como ese.

@pjebs , esa semántica (pánico si no hay un resultado de error en la función actual) es exactamente lo que está discutiendo el documento de diseño en https://github.com/golang/proposal/blob/master/design/32437-try-builtin. md#discusión.

Además, en un intento de hacer que try sea útil no solo dentro de las funciones con un resultado de error, la semántica de try dependía del contexto: si try se usara a nivel de paquete, o si se invocara dentro de una función sin un resultado de error, try entraría en pánico al encontrar un error. (Aparte, debido a esa propiedad, lo incorporado se llamó must en lugar de probar en esa propuesta). Hacer que try (o must) se comporte de esta manera sensible al contexto parecía natural y también bastante útil: permitiría la eliminación de muchas funciones auxiliares definidas por el usuario que se utilizan actualmente en expresiones de inicialización de variables a nivel de paquete. También abriría la posibilidad de usar pruebas unitarias de prueba a través del paquete de prueba.

Sin embargo, la sensibilidad contextual de try se consideró tensa: por ejemplo, el comportamiento de una función que contiene llamadas de prueba podría cambiar silenciosamente (de posiblemente entrar en pánico a no entrar en pánico, y viceversa) si se agrega o elimina un resultado de error de la firma. Esto parecía una propiedad demasiado peligrosa. La solución obvia habría sido dividir la funcionalidad de prueba en dos funciones separadas, debe y prueba (muy similar a lo que sugiere el problema #31442). Pero eso habría requerido dos nuevas funciones integradas, con solo probar conectado directamente a la necesidad inmediata de un mejor soporte de manejo de errores.

@pjebs Eso es _exactamente_ lo que consideramos en una propuesta anterior (consulte el documento detallado, sección sobre iteraciones de diseño, cuarto párrafo):

Además, en un intento de hacer que try sea útil no solo dentro de las funciones con un resultado de error, la semántica de try dependía del contexto: si try se usara a nivel de paquete, o si se invocara dentro de una función sin un resultado de error, try entraría en pánico al encontrar un error. (Aparte, debido a esa propiedad, lo incorporado se denominó debe en lugar de probar en esa propuesta).

El consenso (interno de Go Team) fue que sería confuso que try dependiera del contexto y actuara de manera tan diferente. Por ejemplo, agregar un resultado de error a una función (o eliminarlo) podría cambiar silenciosamente el comportamiento de la función de entrar en pánico a no entrar en pánico (o viceversa).

@griesemer Gracias por la aclaración sobre la reescritura. Me alegro de que se compilará.

Entiendo que los ejemplos fueron traducciones que no anotaron los errores. Traté de argumentar que try hace que sea más difícil hacer una buena anotación de errores en situaciones comunes, y que la anotación de errores es muy importante para la comunidad. Una gran parte de los comentarios hasta ahora han estado explorando formas de agregar un mejor soporte de anotación a try .

Acerca de tener que manejar los errores de manera diferente, no estoy de acuerdo con que sea una señal de que la preocupación de la función es demasiado amplia. He estado traduciendo algunos ejemplos de código real reclamado de los comentarios y colocándolos en un menú desplegable en la parte inferior de mi comentario original , y el ejemplo en https://github.com/golang/go/issues/32437#issuecomment - 499007288 Creo que demuestra bien un caso común:

func (c *Config) Build() error {
    pkgPath, err := c.load()
    if err != nil { return nil, errors.WithMessage(err, "load config dir") }

    b := bytes.NewBuffer(nil)
    err = templates.ExecuteTemplate(b, "main", c)
    if err != nil { return nil, errors.WithMessage(err, "execute main template") }

    buf, err := format.Source(b.Bytes())
    if err != nil { return nil, errors.WithMessage(err, "format main template") }

    target := fmt.Sprintf("%s.go", filename(pkgPath))
    err = ioutil.WriteFile(target, buf, 0644)
    if err != nil { return nil, errors.WithMessagef(err, "write file %s", target) }
    // ...
}

El propósito de esa función es ejecutar una plantilla en algunos datos en un archivo. No creo que deba dividirse, y sería desafortunado si todos esos errores obtuvieran la línea en la que se crearon a partir de un aplazamiento. Eso puede estar bien para los desarrolladores, pero es mucho menos útil para los usuarios.

Creo que también es una pequeña señal de lo sutiles que eran los errores defer wrap(&err, "message: %v", err) y de cómo tropezaron incluso con los programadores experimentados de Go.

Para resumir mi argumento : creo que la anotación de errores es más importante que la verificación de errores basada en expresiones, y podemos reducir bastante el ruido al permitir que la verificación de errores basada en declaraciones sea una línea en lugar de tres. Gracias.

@griesemer , lo siento, leí una sección diferente que discutía el pánico y no vi la discusión sobre los peligros.

@zeebo Gracias por este ejemplo. Parece que usar una instrucción if es exactamente la elección correcta en este caso. Pero claro, formatear los condicionales en una sola línea puede agilizar esto un poco.

Me gustaría mencionar una vez más la idea de un controlador como segundo argumento para try , pero con la adición de que el argumento del controlador sea _requerido_, pero nulo. Esto hace que el manejo del error sea el predeterminado, en lugar de la excepción. En los casos en los que realmente desee pasar el error sin cambios, simplemente proporcione un valor nulo al controlador y try se comportará como en la propuesta original, pero el argumento nulo actuará como una señal visual de que el no se maneja el error. Será más fácil de detectar durante la revisión del código.

file := try(os.Open("my_file.txt"), nil)

¿Qué debería suceder si se proporciona el controlador pero es nulo? ¿Debería probar pánico o tratarlo como un controlador de errores ausente?

Como se mencionó anteriormente, try se comportará de acuerdo con la propuesta original. No existiría un controlador de errores ausente, solo uno nulo.

¿Qué sucede si se invoca el controlador con un error no nulo y luego devuelve un resultado nulo? ¿Significa esto que el error está "cancelado"? ¿O debería la función envolvente regresar con un error nulo?

Creo que la función envolvente regresaría con un error nulo. Sería potencialmente muy confuso si try a veces pudiera continuar la ejecución incluso después de recibir un valor de error distinto de cero. Esto permitiría que los controladores "se ocupen" del error en algunas circunstancias. Este comportamiento podría ser útil en una función de estilo "obtener o crear", por ejemplo.

func getOrCreateObject(obj *object) error {
    defaultObjectHandler := func(err error) error {
        if err == ObjectDoesNotExistErr {
            *obj = object{}
            return nil
        }
        return fmt.Errorf("getting or creating object: %v", err)
    }

    *obj = try(db.getObject(), defaultObjectHandler)
}

Tampoco estaba claro si permitir un controlador de errores opcional llevaría a los programadores a ignorar por completo el manejo adecuado de errores. También sería fácil hacer un manejo adecuado de errores en todas partes, pero perder una sola ocurrencia de un intento. Etcétera.

Creo que ambas preocupaciones se alivian al hacer que el controlador sea un argumento necesario y nulo. Requiere que los programadores tomen una decisión consciente y explícita de que no manejarán su error.

Como beneficio adicional, creo que requerir el controlador de errores también desalienta los try profundamente anidados porque son menos breves. Algunos pueden ver esto como un inconveniente, pero creo que es un beneficio.

@velovix Me encanta la idea, pero ¿por qué se requiere el controlador de errores? ¿No puede ser nil por defecto? ¿Por qué necesitamos una "pista visual"?

@griesemer ¿Qué pasa si se adopta la idea de @velovix pero con builtin que contiene una función predefinida que convierte err en pánico Y eliminamos el requisito de que la función general tenga un valor de retorno de error?

La idea es que, si la función general no devuelve un error, usar try sin el controlador de errores es un error de tiempo de compilación.

El controlador de errores también se puede usar para envolver el error que pronto se devolverá usando varias bibliotecas, etc. en la ubicación del error, en lugar de un defer en la parte superior que modifica un error devuelto con nombre.

@pjebs

¿Por qué se requiere el controlador de errores? ¿No puede ser nulo por defecto? ¿Por qué necesitamos una "pista visual"?

Esto es para abordar las preocupaciones que

1. La propuesta try , tal como está ahora, podría desanimar a las personas a brindar contexto a sus errores porque hacerlo no es tan sencillo.

Tener un controlador en primer lugar hace que proporcionar contexto sea más fácil, y que el controlador sea un argumento requerido envía un mensaje: el caso recomendado común es manejar o contextualizar el error de alguna manera, no simplemente pasarlo a la pila. Está en línea con la recomendación general de la comunidad Go.

1. Una preocupación del documento de propuesta original. Lo cité en mi primer comentario:

Tampoco estaba claro si permitir un controlador de errores opcional llevaría a los programadores a ignorar por completo el manejo adecuado de errores. También sería fácil hacer un manejo adecuado de errores en todas partes, pero perder una sola ocurrencia de un intento. Etcétera.

Tener que pasar un nil explícito hace que sea más difícil olvidarse de manejar un error correctamente. Debe decidir explícitamente no manejar el error en lugar de hacerlo implícitamente omitiendo un argumento.

Pensando más en el retorno condicional mencionado brevemente en https://github.com/golang/go/issues/32437#issuecomment -498947603.
Parece
return if f, err := os.Open("/my/file/path"); err != nil
sería más compatible con el aspecto del if existente de Go.

Si agregamos una regla para la instrucción return if que
cuando la expresión de la última condición (como err != nil ) no está presente,y la última variable de la declaración en la sentencia return if es del tipo error ,entonces el valor de la última variable se comparará automáticamente con nil como condición implícita.

Entonces, la instrucción return if se puede abreviar en:
return if f, err := os.Open("my/file/path")

Lo cual está muy cerca de la relación señal-ruido que proporciona el try .
Si cambiamos return if a try , se convierte en
try f, err := os.Open("my/file/path")
De nuevo se vuelve similar a otras variaciones propuestas de try en este hilo, al menos sintácticamente.
Personalmente, sigo prefiriendo return if a try en este caso porque hace que los puntos de salida de una función sean muy explícitos. Por ejemplo, cuando depuro, a menudo resalto la palabra clave return dentro del editor para identificar todos los puntos de salida de una función grande.

Desafortunadamente, tampoco parece ayudar lo suficiente con el inconveniente de insertar el registro de depuración.
A menos que también permitamos un bloque de $ body por return if , como
Original:

        return if f, err := os.Open("my/path") 

Al depurar:

-       return if f, err := os.Open("my/path") 
+       return if f, err := os.Open("my/path") {
+               fmt.Printf("DEBUG: os.Open: %s\n", err)
+       }

Supongo que el significado del bloque de cuerpo de return if es obvio. Se ejecutará antes defer y regresará.

Dicho esto, no tengo quejas con el enfoque de manejo de errores existente en Go.
Estoy más preocupado por cómo la adición del nuevo manejo de errores afectaría la bondad actual de Go.

@velovix Nos gustó bastante la idea de un try con una función de controlador explícita como segundo argumento. Pero había demasiadas preguntas que no tenían respuestas obvias, como dice el documento de diseño. Ha respondido algunas de ellas de una manera que le parece razonable. Es bastante probable (y esa fue nuestra experiencia dentro del Go Team), que alguien más piense que la respuesta correcta es bastante diferente. Por ejemplo, está afirmando que siempre se debe proporcionar el argumento del controlador, pero que puede ser nil , para que quede explícito, no nos importa manejar el error. Ahora, ¿qué sucede si uno proporciona un valor de función (no un literal nil ) y ese valor de función (almacenado en una variable) resulta ser nulo? Por analogía con el valor explícito nil , no se requiere manipulación. Pero otros podrían argumentar que se trata de un error en el código. O, alternativamente, uno podría permitir argumentos de controlador de valor nulo, pero luego una función podría manejar errores de manera inconsistente en algunos casos y no en otros, y no es necesariamente obvio a partir del código cuál lo hace, porque parece como si un controlador estuviera siempre presente . Otro argumento fue que es mejor tener una declaración de nivel superior de un controlador de errores porque deja muy claro que la función maneja los errores. De ahí el defer . Probablemente haya más.

Sería bueno aprender más sobre esta preocupación. El estilo de codificación actual que usa declaraciones if para probar errores es tan explícito como puede ser. Es muy fácil agregar información adicional a un error, de forma individual (para cada si). A menudo, tiene sentido manejar todos los errores detectados en una función de manera uniforme, lo que se puede hacer con un aplazamiento; esto ya es posible ahora. Es el hecho de que ya tenemos todas las herramientas para un buen manejo de errores en el lenguaje, y el problema de que una construcción de controlador no sea ortogonal para diferir, nos llevó a dejar de lado un nuevo mecanismo únicamente para aumentar errores.

@griesemer - IIUC, está diciendo que para contextos de error dependientes del sitio de llamadas, la declaración if actual está bien. Mientras que esta nueva función try es útil para los casos en los que es útil manejar múltiples errores en un solo lugar.

Creo que la preocupación era que, si bien simplemente hacer un if err != nil { return err} puede estar bien en algunos casos, generalmente se recomienda decorar el error antes de regresar. Y esta propuesta parece abordar lo anterior y no hace mucho por lo segundo. Lo que esencialmente significa que se alentará a la gente a usar un patrón de devolución fácil.

@agnivade Tiene razón, esta propuesta no hace exactamente nada para ayudar con la decoración de errores (pero para recomendar el uso de defer ). Una razón es que ya existen mecanismos de lenguaje para esto. Tan pronto como se requiere la decoración de errores, especialmente sobre la base de un error individual, la cantidad adicional de texto fuente para el código de decoración hace que el if sea menos oneroso en comparación. Son los casos en los que no se requiere decoración, o donde la decoración es siempre la misma, donde el texto modelo se convierte en una molestia visible y luego resta valor al código importante.

Ya se alienta a la gente a usar un patrón de devolución fácil, try o no try , solo hay menos para escribir. Ahora que lo pienso, _la única forma de fomentar la decoración de errores es hacer que sea obligatoria_, porque no importa qué soporte de idioma esté disponible, la decoración de errores requerirá más trabajo.

Una forma de endulzar el trato sería permitir solo algo como try (o cualquier notación abreviada análoga) _si_ se proporciona un controlador explícito (posiblemente vacío) en alguna parte (tenga en cuenta que el borrador del diseño original no tenía tal requisito, tampoco).

No estoy seguro de que queramos ir tan lejos. Permítanme reafirmar que un montón de código perfectamente fino, digamos partes internas de una biblioteca, no necesita decorar errores en todas partes. Está bien simplemente propagar los errores y decorarlos justo antes de que abandonen los puntos de entrada de la API, por ejemplo. (De hecho, decorarlos en todas partes solo conducirá a errores excesivamente decorados que, con los verdaderos culpables ocultos, dificultan la localización de los errores importantes; al igual que un registro demasiado detallado puede dificultar ver lo que realmente está sucediendo).

Creo que también podemos agregar una función de captura , que sería un buen par, entonces:

func a() int {
  x := randInt()
  // let's assume that this is what recruiters should "fix" for us
  // or this happens in 3rd-party package.
  if x % 1337 != 0 {
    panic("not l33t enough")
  }
  return x
}

func b() error {
  // if a() panics, then x = 0, err = error{"not l33t enough"}
  x, err := catch(a())
  if err != nil {
    return err
  }
  sendSomewhereElse(x)
  return nil
}

// which could be simplified even further

func c() error {
  x := try(catch(a()))
  sendSomewhereElse(x)
  return nil
}

en este ejemplo, catch() sería recover() pánico y return ..., panicValue .
por supuesto, tenemos un caso de esquina obvio en el que tenemos una función, que también devuelve un error. en este caso, creo que sería conveniente simplemente pasar el valor del error.

así que, básicamente, puede usar catch() para recuperar() los pánicos y convertirlos en errores.
esto me parece bastante divertido, porque Go en realidad no tiene excepciones, pero en este caso tenemos un patrón try()-catch() bastante bueno, que tampoco debería hacer estallar toda su base de código con algo como Java ( catch(Throwable) en Principal + throws LiterallyAnything ). puede procesar fácilmente los pánicos de alguien como si fueran errores habituales. Actualmente tengo alrededor de 6mln+ LoC en Go en mi proyecto actual, y creo que esto simplificaría las cosas al menos para mí.

@griesemer Gracias por su resumen de la discusión.

Me doy cuenta de que falta un punto: algunas personas han argumentado que deberíamos esperar con esta característica hasta que tengamos genéricos, lo que con suerte nos permitirá resolver este problema de una manera más elegante.

Además, también me gusta la sugerencia de @velovix , y aunque aprecio que esto plantee algunas preguntas como se describe en la especificación, creo que se pueden responder fácilmente de una manera razonable, como ya lo hizo @velovix .

Por ejemplo:

• ¿Qué sucede si uno proporciona un valor de función (no un literal nulo) y ese valor de función (almacenado en una variable) resulta ser nulo? => No manejes el error, punto. Esto es útil en caso de que el manejo de errores dependa del contexto y la variable del controlador se establezca dependiendo de si se requiere o no el manejo de errores. No es un error, más bien, es una característica. :)

• Otro argumento fue que es mejor tener una declaración de nivel superior de un controlador de errores porque deja muy claro que la función maneja los errores. => Por lo tanto, defina el controlador de errores en la parte superior de la función como una función de cierre con nombre y utilícelo, de modo que también quede muy claro que se debe manejar el error. Esto no es un problema serio, más bien un requisito de estilo.

¿Qué otras preocupaciones había? Estoy bastante seguro de que todas pueden responderse de manera similar de una manera razonable.

Finalmente, como usted dice, "una forma de endulzar el trato sería permitir solo algo como probar (o cualquier notación de atajo análoga) si se proporciona un controlador explícito (posiblemente vacío) en alguna parte". Creo que si vamos a proceder con esta propuesta, en realidad deberíamos llevarla "hasta aquí", para fomentar un manejo de errores adecuado, "explícito es mejor que implícito".

@griesemer

Ahora, ¿qué sucede si uno proporciona un valor de función (no un literal nulo) y ese valor de función (almacenado en una variable) resulta ser nulo? Por analogía con el valor nulo explícito, no se requiere manipulación. Pero otros podrían argumentar que se trata de un error en el código.

En teoría, esto parece un problema potencial, aunque me está costando conceptualizar una situación razonable en la que un controlador terminaría siendo nulo por accidente. Me imagino que los controladores provendrían más comúnmente de una función de utilidad definida en otro lugar, o como un cierre definido en la función misma. Es probable que ninguno de estos se convierta en cero inesperadamente. En teoría, podría tener un escenario en el que las funciones del controlador se transmitan como argumentos a otras funciones, pero a mis ojos parece bastante exagerado. Tal vez hay un patrón como este del que no estoy al tanto.

Otro argumento fue que es mejor tener una declaración de nivel superior de un controlador de errores porque deja muy claro que la función maneja los errores. De ahí el defer .

Como mencionó @beoran , definir el controlador como un cierre cerca de la parte superior de la función tendría un estilo muy similar, y así es como personalmente espero que las personas usen los controladores con más frecuencia. Si bien aprecio la claridad ganada por el hecho de que todas las funciones que manejan errores usarán defer , puede volverse menos claro cuando una función necesita pivotar en su estrategia de manejo de errores a la mitad de la función. Luego, habrá dos defer para mirar y el lector tendrá que razonar sobre cómo interactuarán entre sí. Esta es una situación en la que creo que un argumento del controlador sería más claro y ergonómico, y creo que este será un escenario _relativamente_ común.

¿Es posible hacerlo funcionar sin corchetes?

es decir algo como:
a := try func(some)

@Cyberax : como ya se mencionó anteriormente, es muy importante que lea detenidamente el documento de diseño antes de publicarlo. Dado que este es un tema de alto tráfico, con mucha gente suscrita.

El documento analiza los operadores frente a las funciones en detalle.

Me gusta mucho más esto que la versión de agosto.

Creo que gran parte de los comentarios negativos, que no se oponen directamente a las devoluciones sin la palabra clave return , se pueden resumir en dos puntos:

1. a la gente no le gustan los parámetros de resultados con nombre, que serían necesarios en la mayoría de los casos
2. desaconseja agregar contexto detallado a los errores

Ver por ejemplo:

• https://github.com/golang/go/issues/32437#issuecomment-498937169
• https://github.com/golang/go/issues/32437#issuecomment-498967099
• https://github.com/golang/go/issues/32437#issuecomment-499194787
• https://github.com/golang/go/issues/32437#issuecomment-499309304

La refutación de esas dos objeciones es respectivamente:

1. "decidimos que [los parámetros de resultado nombrados] estaban bien"
2. "Nadie te va a obligar a usar try " / no va a ser apropiado para el 100% de los casos

Realmente no tengo nada que decir sobre 1 (no me siento fuertemente al respecto). Pero con respecto a 2, señalaría que la propuesta de agosto no tenía este problema, la mayoría de las contrapropuestas tampoco tienen este problema.

En particular, ni la contrapropuesta tryf (que se ha publicado de forma independiente dos veces en este hilo) ni la contrapropuesta try(X, handlefn) (que formaba parte de las iteraciones de diseño) tenían este problema.

Creo que es difícil argumentar que try , tal como es, alejará a las personas de la decoración de errores con contexto relevante y hacia una única decoración de error genérica por función.

Por estas razones creo que vale la pena tratar de abordar este tema y quiero proponer una posible solución:

1. Actualmente, el parámetro de defer solo puede ser una función o llamada de método. Permita que defer también tenga un nombre de función o un literal de función, es decir

defer func(...) {...}
defer packageName.functionName

1. Cuando panic o deferreturn encuentran este tipo de aplazamiento, llamarán a la función pasando el valor cero para todos sus parámetros.

2. Permitir que try tenga más de un parámetro

3. Cuando try encuentre el nuevo tipo de aplazamiento, llamará a la función pasando un puntero al valor de error como primer parámetro seguido de todos los parámetros propios de try , excepto el primero.

Por ejemplo, dado:

func errorfn() error {
    return errors.New("an error")
}


func f(fail bool) {
    defer func(err *error, a, b, c int) {
        fmt.Printf("a=%d b=%d c=%d\n", a, b, c)
    }
    if fail {
        try(errorfn, 1, 2, 3)
    }
}

sucederá lo siguiente:

f(false)        // prints "a=0 b=0 c=0"
f(true)         // prints "a=1 b=2 c=3"

El código en https://github.com/golang/go/issues/32437#issuecomment -499309304 por @zeebo podría reescribirse como:

func (c *Config) Build() error {
    defer func(err *error, msg string, args ...interface{}) {
        if *err == nil || msg == "" {
            return
        }
        *err = errors.WithMessagef(err, msg, args...)
    }
    pkgPath := try(c.load(), "load config dir")

    b := bytes.NewBuffer(nil)
    try(templates.ExecuteTemplate(b, "main", c), "execute main template")

    buf := try(format.Source(b.Bytes()), "format main template")

    target := fmt.Sprintf("%s.go", filename(pkgPath))
    try(ioutil.WriteFile(target, buf, 0644), "write file %s", target)
    // ...
}

Y definiendo ErrorHandlef como:

func HandleErrorf(err *error, format string, args ...interface{}) {
        if *err != nil && format != "" {
                *err = fmt.Errorf(format + ": %v", append(args, *err)...)
        }
}

daría a todos el tan buscado tryf de forma gratuita, sin tener que introducir cadenas de formato de estilo fmt en el lenguaje principal.

Esta función es compatible con versiones anteriores porque defer no permite expresiones de función como argumento. No introduce nuevas palabras clave.
Los cambios que deben realizarse para implementarlo, además de los descritos en https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md , son:

1. enseñar al analizador sobre el nuevo tipo de aplazamiento
2. cambie el verificador de tipos para verificar que dentro de una función, todos los diferidos que tienen una función como parámetro (en lugar de una llamada) también tienen la misma firma
3. cambie el verificador de tipos para verificar que los parámetros pasados ​​a try coincidan con la firma de las funciones pasadas a defer
4. cambie el backend (?) para generar la llamada deferproc apropiada
5. cambie la implementación de try para copiar sus argumentos en los argumentos de la llamada diferida cuando encuentre una llamada diferida por el nuevo tipo de diferido.

Después de las complejidades del diseño preliminar de check/handle , me sorprendió gratamente ver esta propuesta mucho más simple y pragmática, aunque me decepcionó que haya habido tanto rechazo en su contra.

Es cierto que gran parte del rechazo proviene de personas que están bastante contentas con la verbosidad actual (una posición perfectamente razonable) y que, presumiblemente, no agradecerían ninguna propuesta para aliviarlo. Para el resto de nosotros, creo que esta propuesta alcanza el punto óptimo de ser simple y similar a Go, sin tratar de hacer demasiado y encajar bien con las técnicas existentes de manejo de errores a las que siempre se puede recurrir si try no hizo exactamente lo que querías.

En cuanto a algunos puntos específicos:

1. Lo único que no me gusta de la propuesta es la necesidad de tener un parámetro de retorno de error con nombre cuando se usa defer pero, dicho esto, no puedo pensar en ninguna otra solución que no esté en desacuerdo con la forma en que funciona el resto del lenguaje. Así que creo que tendremos que aceptar esto si se adopta la propuesta.

2. Es una pena que try no funcione bien con el paquete de prueba para funciones que no devuelven un valor de error. Mi propia solución preferida para esto sería tener una segunda función integrada (quizás ptry o must ) que siempre entrara en pánico en lugar de regresar al encontrar un error no nulo y que, por lo tanto, podría ser utilizado con las funciones antes mencionadas (incluyendo main ). Aunque esta idea ha sido rechazada en la presente iteración de la propuesta, tuve la impresión de que era una 'llamada cercana' y, por lo tanto, puede ser elegible para reconsideración.

3. Creo que sería difícil para la gente entender lo que estaban haciendo go try(f) o defer try(f) y, por lo tanto, es mejor prohibirlos por completo.

4. Estoy de acuerdo con aquellos que piensan que las técnicas de manejo de errores existentes se verían menos detalladas si go fmt no reescribiera declaraciones de una sola línea if . Personalmente, preferiría una regla simple que permitiera esto para _cualquier_ declaración única if ya sea que se trate del manejo de errores o no. De hecho, nunca he podido entender por qué esto no está permitido actualmente cuando se escriben funciones de una sola línea donde el cuerpo se coloca en la misma línea en la que se permite la declaración.

En el caso de errores de decoración

func myfunc()( err error){
try(thing())
defer func(){
err = errors.Wrap(err,"more context")
}()
}

Esto se siente considerablemente más detallado y doloroso que los paradigmas existentes, y no tan conciso como verificar/manejar. La variante try() sin envoltorio es más concisa, pero parece que las personas terminarán usando una combinación de try y regresa un error simple. No estoy seguro de que me guste la idea de mezclar intentos y devoluciones de errores simples, pero estoy totalmente convencido de los errores de decoración (y espero con ansias Is/As). Hazme pensar que si bien esto es sintácticamente ordenado, no estoy seguro de querer usarlo. verificar/manejar sentí algo que abrazaría más a fondo.

Realmente me gusta la simplicidad de esto y el enfoque de "hacer una cosa bien". En mi intérprete GoAWK sería muy útil: tengo alrededor de 100 construcciones if err != nil { return nil } que simplificaría y ordenaría, y eso está en una base de código bastante pequeña.

He leído la justificación de la propuesta para convertirla en una palabra clave integrada en lugar de una, y se reduce a no tener que ajustar el analizador. Pero, ¿no es una cantidad relativamente pequeña de dolor para los compiladores y los escritores de herramientas, mientras que tener los paréntesis adicionales y los problemas de legibilidad de esto parece una función pero no es algo será algo que todos los codificadores y codificadores de Go? los lectores tienen que soportar. En mi opinión, el argumento (¿excusa? :-) de que "pero panic() sí controla el flujo" no es suficiente, porque el pánico y la recuperación son, por su propia naturaleza, excepcionales , mientras que try() lo harán ser normal el manejo de errores y el flujo de control.

Definitivamente lo agradecería incluso si esto fuera como está, pero mi fuerte preferencia sería que el flujo de control normal sea claro, es decir, hecho a través de una palabra clave.

Estoy a favor de esta propuesta. Evita mi mayor reserva sobre la propuesta anterior: la no ortogonalidad de handle con respecto a defer .

Me gustaría mencionar dos aspectos que no creo que se hayan destacado anteriormente.

En primer lugar, aunque esta propuesta no facilita agregar texto de error específico del contexto a un error, _sí_ facilita agregar información de seguimiento de errores de marco de pila a un error: https://play.golang.org/p /YL1MoqR08E6

En segundo lugar, try podría decirse que es una solución justa para la mayoría de los problemas subyacentes a https://github.com/golang/go/issues/19642. Para tomar un ejemplo de ese problema, podría usar try para evitar escribir todos los valores devueltos cada vez. Esto también es potencialmente útil cuando se devuelven tipos de estructura por valor con nombres largos.

func (f *Font) viewGlyphData(b *Buffer, x GlyphIndex) (buf []byte, offset, length uint32, err error) {
    xx := int(x)
    if f.NumGlyphs() <= xx {
        try(ErrNotFound)
    }
    i := f.cached.locations[xx+0]
    j := f.cached.locations[xx+1]
    if j < i {
        try(errInvalidGlyphDataLength)
    }
    if j-i > maxGlyphDataLength {
        try(errUnsupportedGlyphDataLength)
    }
    buf, err = b.view(&f.src, int(i), int(j-i))
    return buf, i, j - i, err
}

A mí también me gusta esta propuesta.

Y tengo un pedido.

Como make , ¿podemos permitir que try tome una cantidad variable de parámetros?

• probar (f):
  como anteriormente.
  un valor de error de retorno es obligatorio (como último parámetro de retorno).
  MODELO DE USO MÁS COMÚN
• try(f, doPanic bool):
  como arriba, pero si doPanic, entonces panic(err) en lugar de regresar.
  En este modo, no es necesario un valor de error de retorno.
• probar (f, fn):
  como arriba, pero llama a fn(err) antes de regresar.
  En este modo, no es necesario un valor de error de retorno.

De esta manera, es un elemento integrado que puede manejar todos los casos de uso, sin dejar de ser explícito. Sus ventajas:

• siempre explícito: no es necesario inferir si entrar en pánico o establecer un error y regresar
• admite un controlador específico del contexto (pero no una cadena de controladores)
• admite casos de uso en los que no hay una variable de retorno de error
• admite la semántica must(...)

Si bien if err !=nil { return ... err } repetitivo es ciertamente un tartamudeo feo, estoy con esos
que piensan que la propuesta try() es muy baja en legibilidad y algo inexplícita.
El uso de retornos con nombre también es problemático.

Si se necesita este tipo de limpieza, ¿por qué no try(err) como azúcar sintáctico para
if err !=nil { return err } :

file, err := os.Open("file.go")
try(err)

por

file, err := os.Open("file.go")
if err != nil {
   return err
}

Y si hay más de un valor de retorno, try(err) podría return t1, ... tn, err
donde t1, ... tn son los valores cero de los otros valores devueltos.

Esta sugerencia puede obviar la necesidad de valores de retorno con nombre y ser,
en mi opinión, más fácil de entender y más legible.

Aún mejor, creo que sería:

file, try(err) := os.Open("file.go")

O incluso

file, err? := os.Open("file.go")

Este último es compatible con versiones anteriores (? actualmente no está permitido en los identificadores).

(Esta sugerencia está relacionada con https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring-themes. Pero los ejemplos de temas recurrentes parecen diferentes porque estaba en una etapa en la que todavía se discutía un identificador explícito en lugar de dejar eso a un aplazamiento.)

Gracias al equipo de go por esta cuidada e interesante propuesta.

@rogpeppe comenta si try agrega automáticamente el marco de la pila, no yo, estoy de acuerdo con que desaconseje agregar contexto.

@aarzilli : de acuerdo con su propuesta, ¿es obligatoria una cláusula de aplazamiento cada vez que asignamos parámetros adicionales a tryf ?

que pasa si hago

try(ioutil.WriteFile(target, buf, 0644), "write file %s", target)

y no escribir una función diferida?

@agnivade

¿Qué sucede si hago (...) y no escribo una función diferida?

error de verificación de tipo.

En mi opinión, usar try para evitar escribir todos los valores devueltos es en realidad otro golpe en su contra.

func (f *Font) viewGlyphData(b *Buffer, x GlyphIndex) (buf []byte, offset, length uint32, err error) {
    xx := int(x)
    if f.NumGlyphs() <= xx {
        try(ErrNotFound)
    }
    //...

Entiendo completamente el deseo de evitar tener que escribir return nil, 0, 0, ErrNotFound , pero preferiría resolverlo de otra manera.

La palabra try no significa "retorno". Y así es como se está usando aquí. De hecho, preferiría que la propuesta cambie para que try no pueda tomar un error directamente, porque no quiero que nadie escriba código como ese ^^. Se lee mal . Si le mostraras ese código a un novato, no tendría ni idea de lo que estaba haciendo ese intento.

Si queremos una forma de devolver fácilmente los valores predeterminados y un valor de error, resolvámoslo por separado. Tal vez otro incorporado como

return default(ErrNotFound)

Al menos eso se lee con algún tipo de lógica.

Pero no abusemos try para resolver algún otro problema.

@natefinch si el try incorporado se llama check como en la propuesta original, sería check(err) que se lee considerablemente mejor, en mi opinión.

Dejando eso de lado, no sé si es realmente un abuso escribir try(err) . Se sale de la definición limpiamente. Pero, por otro lado, eso también significa que esto es legal:

a, b := try(1, f(), err)

Supongo que mi principal problema con try es que en realidad es solo un panic que solo sube un nivel... excepto que, a diferencia de panic, es una expresión, no una declaración, por lo que puedes ocultar en medio de una declaración en alguna parte. Eso casi lo hace peor que el pánico.

@natefinch Si lo conceptualizas como un pánico que sube un nivel y luego hace otras cosas, parece bastante complicado. Sin embargo, lo conceptualizo de manera diferente. Las funciones que devuelven errores en Go están devolviendo efectivamente un resultado, para tomar prestado libremente de la terminología de Rust. try es una utilidad que desempaqueta el resultado y devuelve un "resultado de error" si error != nil , o desempaqueta la parte T del resultado si error == nil .

Por supuesto, en Go en realidad no tenemos objetos de resultado, pero es efectivamente el mismo patrón y try parece una codificación natural de ese patrón. Creo que cualquier solución a este problema tendrá que codificar algún aspecto del manejo de errores, y la interpretación de try me parece razonable. Otros y yo sugerimos ampliar un poco la capacidad de try para que se ajuste mejor a los patrones de manejo de errores de Go existentes, pero el concepto subyacente sigue siendo el mismo.

@ugorji La variante try(f, bool) que propone suena como la must de #32219.

@ugorji La variante try(f, bool) que propone suena como la must de #32219.

Sí lo es. Simplemente sentí que los 3 casos podrían manejarse con una función incorporada singular y satisfacer todos los casos de uso con elegancia.

Dado que try() ya es mágico y consciente del valor de retorno de error, ¿podría aumentarse para devolver también un puntero a ese valor cuando se llama en forma nula (argumento cero)? Eso eliminaría la necesidad de devoluciones con nombre, y creo que ayudaría a correlacionar visualmente de dónde se espera que provenga el error en las declaraciones diferidas. Por ejemplo:

func foo() error {
  defer fmt.HandleErrorf(try(), "important foo context info")
  try(bar())
  try(baz())
  try(etc())
}

@ugorji
Creo que el booleano en try(f, bool) haría que fuera difícil de leer y fácil de pasar por alto. Me gusta su propuesta, pero para el caso de pánico, creo que podría omitirse para que los usuarios escriban eso dentro del controlador de su tercera viñeta, por ejemplo, try(f(), func(err error) { panic('at the disco'); }) , esto lo hace más explícito para los usuarios que un try(f(), true) oculto.

@ugorji
Creo que el booleano en try(f, bool) haría que fuera difícil de leer y fácil de pasar por alto. Me gusta su propuesta, pero para el caso de pánico, creo que podría omitirse para que los usuarios escriban eso dentro del controlador de su tercera viñeta, por ejemplo, try(f(), func(err error) { panic('at the disco'); }) , esto lo hace más explícito para los usuarios que un try(f(), true) oculto.

Pensándolo bien, tiendo a estar de acuerdo con su posición y su razonamiento, y todavía parece elegante como una sola línea.

@patrick-nyt es otro defensor de la _sintaxis de asignación_ para activar una prueba nula, en https://github.com/golang/go/issues/32437#issuecomment -499533464

Este concepto aparece en 13 respuestas separadas a la propuesta de verificación/manejo
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -temas

f, ?return := os.Open(...)
f, ?panic  := os.Open(...)

¿Por qué? Porque se lee como Go 1, mientras que try() y check no.

https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md#draft-design

Una objeción a try parece ser que es una expresión. Supongamos, en cambio, que hay una declaración de sufijo unario ? que significa retorno si no es nulo. Aquí está el ejemplo de código estándar (suponiendo que se agregue mi paquete diferido propuesto ):

func CopyFile(src, dst string) error {
    var err error // Don't need a named return because err is explicitly named
    defer deferred.Annotate(&err, "copy %s %s", src, dst)

    r, err := os.Open(src)
    err?
    defer deferred.AnnotatedExec(&err, r.Close)

    w, err := os.Create(dst)
    err?
    defer deferred.AnnotatedExec(&err, r.Close)

    defer deferred.Cond(&err, func(){ os.Remove(dst) })
    _, err = io.Copy(w, r)

    return err
}

El ejemplo de pgStore:

func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    err?

    defer deferred.Cond(&err, func(){ tx.Rollback() })

    var res int64 
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    // tricky bit: this would not change the value of err 
    // but the deferred.Cond would still be triggered by err being set before
    deferred.Format(err, "insert table")?

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    deferred.Format(err, "insert table2")?

    return tx.Commit()
}

Me gusta esto de @jargv :

Dado que try() ya es mágico y consciente del valor de retorno de error, ¿podría aumentarse para devolver también un puntero a ese valor cuando se llama en forma nula (argumento cero)? Eso eliminaría la necesidad de devoluciones con nombre

Pero en lugar de sobrecargar el nombre try en función de la cantidad de argumentos, creo que podría haber otra función mágica incorporada, digamos reterr o algo así.

He informado a través de algunos paquetes que se usan con mucha frecuencia, buscando el código go que "sufre" del manejo de errores, pero debe haber sido bien pensado antes de escribirlo, tratando de descubrir qué "magia" haría el try() propuesto.
Actualmente, a menos que no haya entendido bien la propuesta, muchas de ellas (por ejemplo, el manejo de errores no superbásico) no ganarían mucho, o tendrían que quedarse con el estilo de manejo de errores "antiguo".
Ejemplo de net/http/request.go:

func (r *Request) write(w io.Writer, usingProxy bool, extraHeaders Header, waitForContinue func() bool) (err error) {
`

trace := httptrace.ContextClientTrace(r.Context())
if trace != nil && trace.WroteRequest != nil {
    defer func() {
        trace.WroteRequest(httptrace.WroteRequestInfo{
            Err: err,
        })
    }()
}

// Find the target host. Prefer the Host: header, but if that
// is not given, use the host from the request URL.
//
// Clean the host, in case it arrives with unexpected stuff in it.
host := cleanHost(r.Host)
if host == "" {
    if r.URL == nil {
        return errMissingHost
    }
    host = cleanHost(r.URL.Host)
}

// According to RFC 6874, an HTTP client, proxy, or other
// intermediary must remove any IPv6 zone identifier attached
// to an outgoing URI.
host = removeZone(host)

ruri := r.URL.RequestURI()
if usingProxy && r.URL.Scheme != "" && r.URL.Opaque == "" {
    ruri = r.URL.Scheme + "://" + host + ruri
} else if r.Method == "CONNECT" && r.URL.Path == "" {
    // CONNECT requests normally give just the host and port, not a full URL.
    ruri = host
    if r.URL.Opaque != "" {
        ruri = r.URL.Opaque
    }
}
if stringContainsCTLByte(ruri) {
    return errors.New("net/http: can't write control character in Request.URL")
}
// TODO: validate r.Method too? At least it's less likely to
// come from an attacker (more likely to be a constant in
// code).

// Wrap the writer in a bufio Writer if it's not already buffered.
// Don't always call NewWriter, as that forces a bytes.Buffer
// and other small bufio Writers to have a minimum 4k buffer
// size.
var bw *bufio.Writer
if _, ok := w.(io.ByteWriter); !ok {
    bw = bufio.NewWriter(w)
    w = bw
}

_, err = fmt.Fprintf(w, "%s %s HTTP/1.1\r\n", valueOrDefault(r.Method, "GET"), ruri)
if err != nil {
    return err
}

// Header lines
_, err = fmt.Fprintf(w, "Host: %s\r\n", host)
if err != nil {
    return err
}
if trace != nil && trace.WroteHeaderField != nil {
    trace.WroteHeaderField("Host", []string{host})
}

// Use the defaultUserAgent unless the Header contains one, which
// may be blank to not send the header.
userAgent := defaultUserAgent
if r.Header.has("User-Agent") {
    userAgent = r.Header.Get("User-Agent")
}
if userAgent != "" {
    _, err = fmt.Fprintf(w, "User-Agent: %s\r\n", userAgent)
    if err != nil {
        return err
    }
    if trace != nil && trace.WroteHeaderField != nil {
        trace.WroteHeaderField("User-Agent", []string{userAgent})
    }
}

// Process Body,ContentLength,Close,Trailer
tw, err := newTransferWriter(r)
if err != nil {
    return err
}
err = tw.writeHeader(w, trace)
if err != nil {
    return err
}

err = r.Header.writeSubset(w, reqWriteExcludeHeader, trace)
if err != nil {
    return err
}

if extraHeaders != nil {
    err = extraHeaders.write(w, trace)
    if err != nil {
        return err
    }
}

_, err = io.WriteString(w, "\r\n")
if err != nil {
    return err
}

if trace != nil && trace.WroteHeaders != nil {
    trace.WroteHeaders()
}

// Flush and wait for 100-continue if expected.
if waitForContinue != nil {
    if bw, ok := w.(*bufio.Writer); ok {
        err = bw.Flush()
        if err != nil {
            return err
        }
    }
    if trace != nil && trace.Wait100Continue != nil {
        trace.Wait100Continue()
    }
    if !waitForContinue() {
        r.closeBody()
        return nil
    }
}

if bw, ok := w.(*bufio.Writer); ok && tw.FlushHeaders {
    if err := bw.Flush(); err != nil {
        return err
    }
}

// Write body and trailer
err = tw.writeBody(w)
if err != nil {
    if tw.bodyReadError == err {
        err = requestBodyReadError{err}
    }
    return err
}

if bw != nil {
    return bw.Flush()
}
return nil

}
`

o como se usa en una prueba exhaustiva como pprof/profile/profile_test.go:
`
func checkAggregation(prof *Perfil, a *aggTest) error {
// Comprobar que se conservó el número total de muestras para las filas.
totales := int64(0)

samples := make(map[string]bool)
for _, sample := range prof.Sample {
    tb := locationHash(sample)
    samples[tb] = true
    total += sample.Value[0]
}

if total != totalSamples {
    return fmt.Errorf("sample total %d, want %d", total, totalSamples)
}

// Check the number of unique sample locations
if a.rows != len(samples) {
    return fmt.Errorf("number of samples %d, want %d", len(samples), a.rows)
}

// Check that all mappings have the right detail flags.
for _, m := range prof.Mapping {
    if m.HasFunctions != a.function {
        return fmt.Errorf("unexpected mapping.HasFunctions %v, want %v", m.HasFunctions, a.function)
    }
    if m.HasFilenames != a.fileline {
        return fmt.Errorf("unexpected mapping.HasFilenames %v, want %v", m.HasFilenames, a.fileline)
    }
    if m.HasLineNumbers != a.fileline {
        return fmt.Errorf("unexpected mapping.HasLineNumbers %v, want %v", m.HasLineNumbers, a.fileline)
    }
    if m.HasInlineFrames != a.inlineFrame {
        return fmt.Errorf("unexpected mapping.HasInlineFrames %v, want %v", m.HasInlineFrames, a.inlineFrame)
    }
}

// Check that aggregation has removed finer resolution data.
for _, l := range prof.Location {
    if !a.inlineFrame && len(l.Line) > 1 {
        return fmt.Errorf("found %d lines on location %d, want 1", len(l.Line), l.ID)
    }

    for _, ln := range l.Line {
        if !a.fileline && (ln.Function.Filename != "" || ln.Line != 0) {
            return fmt.Errorf("found line %s:%d on location %d, want :0",
                ln.Function.Filename, ln.Line, l.ID)
        }
        if !a.function && (ln.Function.Name != "") {
            return fmt.Errorf(`found file %s location %d, want ""`,
                ln.Function.Name, l.ID)
        }
    }
}

return nil

}
`
Estos son dos ejemplos que se me ocurren en los que uno diría: "Me gustaría una mejor opción de manejo de errores"

¿Alguien puede demostrar cómo mejorarían estos usando try() ?

Estoy mayoritariamente a favor de esta propuesta.

Mi principal preocupación, compartida con muchos comentaristas, es sobre los parámetros de resultados con nombre. La propuesta actual sin duda fomenta mucho más el uso de parámetros de resultados con nombre y creo que sería un error. No creo que esto sea simplemente una cuestión de estilo, como dice la propuesta: los resultados con nombre son una característica sutil del lenguaje que, en muchos casos, hace que el código sea más propenso a errores o menos claro. Después de ~8 años de leer y escribir código Go, realmente solo uso parámetros de resultado con nombre para dos propósitos:

• Documentación de parámetros de resultados
• Manipular un valor de resultado (generalmente un error ) dentro de un aplazamiento

Para atacar este problema desde una nueva dirección, aquí hay una idea que no creo que se alinee estrechamente con nada de lo que se haya discutido en el documento de diseño o en este hilo de comentarios del problema. Llamémoslo "error-diferir":

Permita que se use defer para llamar a funciones con un parámetro de error implícito.

Así que si tienes una función

func f(err error, t1 T1, t2 T2, ..., tn Tn) error

Luego, en una función g donde el último parámetro de resultado tiene tipo error (es decir, cualquier función donde se pueda usar try ), una llamada a f puede diferir de la siguiente manera:

func g() (R0, R0, ..., error) {
    defer f(t0, t1, ..., tn) // err is implicit
}

La semántica de error-defer es:

1. La llamada diferida a f se llama con el último parámetro de resultado de g como primer parámetro de entrada de f
2. f solo se llama si ese error no es nulo
3. El resultado de f se asigna al último parámetro de resultado de g

Entonces, para usar un ejemplo del antiguo documento de diseño de manejo de errores, usando error-defer and try, podríamos hacer

func printSum(a, b string) error {
    defer func(err error) error {
        return fmt.Errorf("printSum(%q + %q): %v", a, b, err)
    }()
    x := try(strconv.Atoi(a))
    y := try(strconv.Atoi(b))
    fmt.Println("result:", x+y)
    return nil
}

Así es como funcionaría HandleErrorf:

func printSum(a, b string) error {
    defer handleErrorf("printSum(%q + %q)", a, b)
    x := try(strconv.Atoi(a))
    y := try(strconv.Atoi(b))
    fmt.Println("result:", x+y)
    return nil
}

func handleErrorf(err error, format string, args ...interface{}) error {
    return fmt.Errorf(format+": %v", append(args, err)...)
}

Un caso de esquina que debería resolverse es cómo manejar los casos en los que es ambiguo qué forma de aplazamiento estamos usando. Creo que eso solo sucede con funciones (muy inusuales) con firmas como esta:

func(error, ...error) error

Parece razonable decir que este caso se maneja de forma que no se aplacen los errores (y esto preserva la compatibilidad con versiones anteriores).

Pensando en esta idea durante los últimos días, es un poco mágica, pero evitar los parámetros de resultado con nombre es una gran ventaja a su favor. Dado que try fomenta un mayor uso de defer para la manipulación de errores, tiene sentido que defer podría extenderse para adaptarse mejor a ese propósito. Además, hay una cierta simetría entre try y error-defer.

Finalmente, los aplazamientos de errores son útiles hoy en día incluso sin intentarlo, ya que suplantan el uso de parámetros de resultados con nombre para manipular las devoluciones de errores. Por ejemplo, aquí hay una versión editada de un código real:

// GetMulti retrieves multiple files through the cache at once and returns its
// results as a slice parallel to the input.
func (c *FileCache) GetMulti(keys []string) (_ []*File, err error) {
    files := make([]*file, len(keys))

    defer func() {
        if err != nil {
            // Return any successfully retrieved files.
            for _, f := range files {
                if f != nil {
                    c.put(f)
                }
            }
        }
    }()

    // ...
}

Con error-defer, esto se convierte en:

// GetMulti retrieves multiple files through the cache at once and returns its
// results as a slice parallel to the input.
func (c *FileCache) GetMulti(keys []string) ([]*File, error) {
    files := make([]*file, len(keys))

    defer func(err error) error {
        // Return any successfully retrieved files.
        for _, f := range files {
            if f != nil {
                c.put(f)
            }
        }
        return err
    }()

    // ...
}

@beoran Con respecto a su comentario de que deberíamos esperar a los genéricos. Los genéricos no ayudarán aquí; lea las preguntas frecuentes .

Con respecto a sus sugerencias sobre el comportamiento predeterminado de try de 2 argumentos de @velovix : como dije antes , su idea de cuál es la opción obviamente razonable es la pesadilla de otra persona.

¿Puedo sugerir que continuemos esta discusión una vez que evolucione un amplio consenso de que try con un controlador de errores explícito es una mejor idea que el try mínimo actual? En ese punto, tiene sentido discutir los puntos finos de tal diseño.

(De hecho, me gusta tener un manejador. Es una de nuestras propuestas anteriores. Y si adoptamos try tal como están, aún podemos avanzar hacia un try con un manejador en un avance -forma compatible - al menos si el controlador es opcional. Pero demos un paso a la vez.)

@aarzilli Gracias por tu sugerencia .

Siempre que los errores de decoración sean opcionales, la gente se inclinará por no hacerlo (después de todo, es un trabajo extra). Véase también mi comentario aquí .

Por lo tanto, no creo que el try propuesto _desaliente_ a las personas a cometer errores en la decoración (ya están desanimados incluso con el if por la razón anterior); es que try no lo _fomenta_.

(Una forma de alentarlo es vincularlo a try : solo se puede usar try si también se decora el error, o se excluye explícitamente).

Pero volviendo a tus sugerencias: creo que estás introduciendo mucha más maquinaria aquí. Cambiar la semántica de defer solo para que funcione mejor para try no es algo que nos gustaría considerar a menos que esos cambios defer sean beneficiosos de una manera más general. Además, su sugerencia vincula defer junto con try y, por lo tanto, hace que ambos mecanismos sean menos ortogonales; algo que querríamos evitar.

Pero lo que es más importante, dudo que quieras obligar a todos a escribir un defer solo para que puedan usar try . Pero sin hacer eso, volvemos al punto de partida: la gente se inclinará por no decorar los errores.

(Me gusta tener un controlador, para el caso. Es una de nuestras propuestas anteriores. Y si adoptamos la prueba tal como está, aún podemos avanzar hacia una prueba con un controlador de una manera compatible con versiones posteriores, al menos si el controlador es opcional. Pero demos un paso a la vez).

Claro, tal vez un enfoque de varios pasos sea el camino a seguir. Si agregamos un argumento de controlador opcional en el futuro, se podrían crear herramientas para advertir al escritor de un try no controlado con el mismo espíritu que la herramienta errcheck . De todos modos, agradezco sus comentarios!

@alanfo Gracias por sus comentarios positivos.

Con respecto a los puntos que planteas:

1) Si el único problema con try es el hecho de que uno tendrá que nombrar un retorno de error para que podamos decorar un error a través defer , creo que estamos bien. Si nombrar el resultado resulta ser un problema real, podríamos abordarlo. Un mecanismo simple en el que puedo pensar sería una variable predeclarada que es un alias para un resultado de error (piense en ello como que contiene el error que desencadenó el try más reciente). Puede haber mejores ideas. No propusimos esto porque ya existe un mecanismo en el lenguaje, que es nombrar el resultado.
2) try y pruebas: esto se puede abordar y hacer que funcione. Ver el documento detallado.
3) Esto se aborda explícitamente en el documento detallado.
4) Reconocido.

@benhoyt Gracias por sus comentarios positivos.

Si el argumento principal en contra de esta propuesta es el hecho de que try está integrado, estamos en un buen lugar. El uso de un integrado es simplemente una solución pragmática para el problema de la compatibilidad con versiones anteriores (sucede que no causa trabajo adicional para el analizador, las herramientas, etc., pero eso es solo un buen beneficio secundario, no la razón principal). También hay algunos beneficios de tener que escribir paréntesis, esto se analiza en detalle en el documento de diseño (sección sobre Propiedades del diseño propuesto).

Dicho todo esto, si el uso de una función incorporada es lo más sensacional, deberíamos considerar la palabra clave try . Sin embargo, no será compatible con versiones anteriores del código existente, ya que la palabra clave puede entrar en conflicto con los identificadores existentes.

(Para completar, también existe la opción de un operador como ? , que sería compatible con versiones anteriores. Sin embargo, no me parece la mejor opción para un lenguaje como Go. Pero, de nuevo, si eso es todo lo que se necesita para hacer que try sea apetecible, tal vez deberíamos considerarlo).

@ugorji Gracias por sus comentarios positivos.

try podría extenderse para tomar un argumento adicional. Nuestra preferencia sería tomar solo una función con la firma func (error) error . Si quiere entrar en pánico, es fácil proporcionar una función de ayuda de una línea:

func doPanic(err error) error { panic(err) }

Es mejor mantener el diseño de try simple.

@ patrick-nyt Lo que estás sugiriendo :

file, err := os.Open("file.go")
try(err)

será posible con la propuesta actual.

@dpinela , @ugorji Lea también el documento de diseño sobre el tema de must vs try . Es mejor mantener try lo más simple posible. must es un "patrón" común en las expresiones de inicialización, pero no hay una necesidad urgente de "arreglarlo".

@jargv Gracias por tu sugerencia . Esta es una idea interesante (ver también mi comentario aquí sobre este tema). Para resumir:

• try(x) funciona según lo propuesto
• try() devuelve un *error que apunta al resultado del error

De hecho, esta sería otra forma de llegar al resultado sin tener que nombrarlo.

@cespare La sugerencia de @jargv me parece mucho más simple que lo que estás proponiendo . Resuelve el mismo problema de acceso al error de resultado. ¿Qué piensas?

Según https://github.com/golang/go/issues/32437#issuecomment -499320588:

func doPanic(err error) error { panic(err) }

Anticipo que esta función sería bastante común. ¿Podría esto estar predefinido en "incorporado" (o en algún otro lugar en un paquete estándar, por ejemplo errors )?

Lástima que no anticipes genéricos lo suficientemente potentes como para implementar
intentarlo, en realidad hubiera esperado que fuera posible hacerlo.

Sí, esta propuesta podría ser un primer paso, aunque no le veo mucha utilidad
yo mismo tal como está ahora.

Por supuesto, este problema quizás se centre demasiado en alternativas detalladas,
pero demuestra que muchos participantes no están completamente satisfechos con
eso. Lo que parece faltar es un amplio consenso sobre esta propuesta...

Op vr 7 jun. 2019 01:04 schreef pj [email protected] :

Asper #32437 (comentario)
https://github.com/golang/go/issues/32437#issuecomment-499320588 :

func doPanic(err error) error { panic(err) }

Anticipo que esta función sería bastante común. ¿Podría ser esto predefinido?
en "incorporado"?

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/golang/go/issues/32437?email_source=notifications&email_token=AAARM6OOOLLYO5ZCE6VVL2TPZGJWRA5CNFSM4HTGCZ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXEMYZY#issue,98-4919 6
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAARM6K5AOR2DES4QDTNLSTPZGJWRANCNFSM4HTGCZ7Q
.

@pjebs , he escrito la función equivalente docenas de veces. Normalmente lo llamo “orDie” o “check”. Es tan simple que no hay necesidad real de hacerlo parte de la biblioteca estándar. Además, diferentes personas pueden querer iniciar sesión o lo que sea antes de la terminación.

@beoran Quizás podría ampliar la conexión entre los genéricos y el manejo de errores. Cuando pienso en ellos, parecen dos cosas diferentes. Los genéricos no son un cajón de sastre que puede abordar todos los problemas con el idioma. Es la capacidad de escribir una sola función que puede operar en múltiples tipos.

Esta propuesta específica de manejo de errores trata de reducir el modelo mediante la introducción de una función predeclarada try que cambia el control de flujo en algunas circunstancias. Los genéricos nunca cambiarán el flujo de control. Así que realmente no veo la relación.

Mi reacción inicial a esto fue un 👎 ya que imaginé que manejar varias llamadas propensas a errores dentro de una función haría que el error defer fuera confuso. Después de leer toda la propuesta, cambié mi reacción a un ❤️ y un 👍 cuando aprendí que esto todavía se puede lograr con una complejidad relativamente baja.

@carlmjohnson Sí, es simple pero...

He escrito la función equivalente docenas de veces.

Las ventajas de una función predeclarada son:

1. Podemos una sola línea
2. No necesitamos volver a declarar la función err => panic en cada paquete que usamos, o mantener una ubicación común para ella. Dado que probablemente sea común para todos en la comunidad de Go, el "paquete estándar" es _ la _ ubicación común para él.

@griesemer Con la variante del controlador de errores de la propuesta de prueba original, ya no se requiere el requisito de la función general para devolver el error.

Cuando pregunté por primera vez sobre el err => pánico, me señalaron que la propuesta lo consideraba pero lo consideraba demasiado peligroso (por una buena razón). Pero si usamos try() sin un controlador de errores en un escenario donde la función general no devuelve un error, convertirlo en un error en tiempo de compilación alivia la preocupación discutida en la propuesta.

@pjebs El requisito de la función general para devolver un error no se requería en el diseño original _si_ se proporcionó un controlador de errores. Pero es solo otra complicación de try . Es _mucho_ mejor mantenerlo simple. En cambio, sería más claro tener una función must separada, que siempre entra en pánico en caso de error (pero de lo contrario es como try ). Entonces es obvio lo que sucede en el código y uno no tiene que mirar el contexto.

El principal atractivo de tener un must este tipo sería que podría usarse con pruebas unitarias; especialmente si el paquete testing se ajustó adecuadamente para recuperarse de los pánicos causados ​​por must y reportarlos como fallas de prueba de una manera agradable. Pero, ¿por qué agregar otro nuevo mecanismo de idioma cuando solo podemos ajustar el paquete de prueba para que también acepte la función de prueba de la forma TestXxx(t *testing.T) error ? Si devuelven un error, lo que parece bastante natural después de todo (quizás deberíamos haber hecho esto desde el principio), entonces try funcionará bien. Las pruebas locales necesitarán un poco más de trabajo, pero probablemente sea factible.

El otro uso relativamente común de must es en expresiones de inicialización global ( must(regexp.Compile... , etc.). Si sería "bueno tenerlo", pero eso no necesariamente lo eleva al nivel requerido para una nueva función de idioma.

@griesemer Dado que must está vagamente relacionado con try , y dado que el impulso es hacia la implementación try , ¿no cree que es bueno considerar must ?

Lo más probable es que si no se discute en esta ronda, simplemente no se implementará ni se considerará seriamente, al menos durante más de 3 años (o tal vez nunca). La superposición en la discusión también sería buena en lugar de comenzar desde cero y reciclar las discusiones.

Mucha gente ha dicho que must complementa muy bien a try .

@pjebs Ciertamente, no parece que haya ningún "impulso hacia la implementación try " en este momento... - Y también publicamos esto hace solo dos días. Tampoco se ha decidido nada. Démosle un poco de tiempo a esto.

No se nos ha escapado que must encaja muy bien con try , pero eso no es lo mismo que hacerlo parte del lenguaje. Solo hemos comenzado a explorar este espacio con un grupo más amplio de personas. Realmente no sabemos todavía qué podría surgir a favor o en contra. Gracias.

Después de pasar horas leyendo todos los comentarios y el documento de diseño detallado, quería agregar mis puntos de vista a esta propuesta.

Haré todo lo posible para respetar la solicitud de @ianlancetaylor de no solo reafirmar los puntos anteriores, sino agregar nuevos comentarios a la discusión. Sin embargo, no creo que pueda hacer los nuevos comentarios sin hacer referencia a los comentarios anteriores.

Preocupaciones

Lamentable sobrecarga de diferir

La preferencia por sobrecargar la naturaleza obvia y directa de defer como alarmante. Si escribo defer closeFile(f) es claro y obvio para mí lo que sucede y por qué; al final de la función que será llamada. Y aunque usar defer para panic() y recover() es menos obvio, casi nunca lo uso y casi nunca lo veo cuando leo el código de otros.

Spoo para sobrecargar defer para manejar también los errores no es obvio y confuso. ¿Por qué la palabra clave defer ? ¿ defer no significa _"Hacer más tarde"_ en lugar de _"Quizás para más tarde?"_

También existe la preocupación mencionada por el equipo de Go sobre el rendimiento de defer . Dado eso, parece doblemente desafortunado que se esté considerando defer para el flujo de código _"ruta activa"_.

No hay estadísticas que verifiquen un caso de uso significativo

Como mencionó @prologic , ¿esta propuesta try() se basa en un gran porcentaje de código que usaría este caso de uso, o se basa en cambio en intentar aplacar a aquellos que se han quejado del manejo de errores de Go?

Ojalá supiera cómo brindarles estadísticas de mi base de código sin revisar exhaustivamente cada archivo y tomar notas; No sé cómo @prologic pudo hacerlo, aunque me alegro de haberlo hecho.

Pero, como anécdota, me sorprendería si try() abordara el 5 % de mis casos de uso y sospecharía que abordaría menos del 1 %. ¿Sabes con certeza que otros tienen resultados muy diferentes? ¿Ha tomado un subconjunto de la biblioteca estándar y ha intentado ver cómo se aplicaría?

Debido a que sin estadísticas conocidas de que esto es apropiado para una gran cantidad de código en la naturaleza, tengo que preguntar si este nuevo cambio complicado en el lenguaje que requerirá que todos aprendan los nuevos conceptos realmente aborda una cantidad convincente de casos de uso.

Hace que sea más fácil para los desarrolladores ignorar los errores

Esto es una repetición total de lo que otros han comentado, pero lo que básicamente proporciona try() es análogo en muchos sentidos a simplemente adoptar lo siguiente como código idomático, y este es un código que nunca encontrará su camino en ningún código por sí mismo. -respetando las naves de los desarrolladores:

f, _ := os.Open(filename)

Sé que puedo ser mejor en mi propio código, pero también sé que muchos de nosotros dependemos de la generosidad de otros desarrolladores de Go que publican algunos paquetes tremendamente útiles, pero por lo que he visto en _"Other People's Code(tm)"_ Las mejores prácticas en el manejo de errores a menudo se ignoran.

En serio, ¿realmente queremos que sea más fácil para los desarrolladores ignorar los errores y permitirles contaminar GitHub con paquetes no robustos?

Puede (en su mayoría) ya implementar try() en el espacio del usuario

A menos que no entienda bien la propuesta, que probablemente sea así, aquí hay try() en el Go Playground implementado en userland , aunque con solo un (1) valor de retorno y una interfaz en lugar del tipo esperado:

package main

import (
    "errors"
    "fmt"
    "strings"
)
func main() {
    defer func() {
        r := recover()
        if r != nil && strings.HasPrefix(r.(string),"TRY:") {
            fmt.Printf("Ouch! %s",strings.TrimPrefix(r.(string),"TRY: "))
        }
    }()
    n := try(badjuju()).(int)
    fmt.Printf("Just chillin %dx!",n)   
}
func badjuju() (int,error) {
    return 10, errors.New("this is a really bad error")
}
func try(args ...interface{}) interface{} {
    err,ok := args[1].(error)
    if ok && err != nil {
        panic(fmt.Sprintf("TRY: %s",err.Error()))
    }
    return args[0]
}

Entonces, el usuario podría agregar un try2() , try3() y así sucesivamente dependiendo de cuántos valores devueltos necesitaba devolver.

Pero Go solo necesitaría una (1) función de idioma simple _ pero universal _ para permitir a los usuarios que desean try() implementar su propio soporte, aunque aún requiere una afirmación de tipo explícita. Agregue una capacidad _(totalmente compatible con versiones anteriores)_ para un Go func para devolver un número variable de valores de retorno, por ejemplo:

func try(args ...interface{}) ...interface{} {
    err,ok := args[1].(error)
    if ok && err != nil {
        panic(fmt.Sprintf("TRY: %s",err.Error()))
    }
    return args[0:len(args)-2]
}

Y si aborda los genéricos primero, entonces las aserciones de tipo ni siquiera serían necesarias _ (aunque creo que los casos de uso para los genéricos deberían reducirse agregando elementos integrados para abordar los casos de uso de los genéricos en lugar de agregar la semántica confusa y la ensalada de sintaxis de los genéricos de Java y otros)_

falta de obviedad

Al estudiar el código de la propuesta, encuentro que el comportamiento no es obvio y es algo difícil de razonar.

Cuando veo try() envolviendo una expresión, ¿qué sucederá si se devuelve un error?

¿Se ignorará el error? ¿O saltará al primero o al más reciente defer , y si es así establecerá automáticamente una variable llamada err dentro del cierre que, o lo pasará como un parámetro _(I no ve un parámetro?)_. Y si no es un nombre de error automático, ¿cómo lo nombro? ¿Y eso significa que no puedo declarar mi propia variable err en mi función para evitar conflictos?

¿Y llamará a todos los defer s? ¿En orden inverso o en orden regular?

¿O regresará tanto del cierre como del func donde se devolvió el error? _(Algo que nunca hubiera considerado si no hubiera leído aquí palabras que implican eso.)_

Después de leer la propuesta y todos los comentarios hasta el momento, sinceramente, todavía no sé las respuestas a las preguntas anteriores. ¿Es ese el tipo de característica que queremos agregar a un lenguaje cuyos defensores defienden ser _"Capitán Obvio?"_

Falta de control

Usando defer , parece que el único control que se les daría a los desarrolladores es ramificarse a _(¿el más reciente?)_ defer . Pero en mi experiencia con cualquier método más allá de un func trivial, por lo general es más complicado que eso.

A menudo me ha resultado útil compartir el aspecto del manejo de errores dentro de un func , o incluso en un package , pero luego también tener un manejo más específico compartido en uno o más paquetes.

Por ejemplo, puedo llamar a cinco (5) llamadas de func que devuelven un error() desde dentro de otro func ; vamos a etiquetarlos como A() , B() , C() , D() y E() . Es posible que necesite C() para tener su propio manejo de errores, A() , B() , D() y E() para compartir algunos manejos de errores, y B() y E() para tener un manejo específico.

Pero no creo que sea posible hacer eso con esta propuesta. Al menos no fácilmente.

Sin embargo, irónicamente, Go ya tiene funciones de lenguaje que permiten un alto nivel de flexibilidad que no necesita limitarse a un pequeño conjunto de casos de uso; func sy cierres. Así que mi pregunta retórica es:

_ "¿Por qué no podemos simplemente agregar ligeras mejoras al lenguaje existente para abordar estos casos de uso y no necesitamos agregar nuevas funciones integradas o aceptar una semántica confusa?" _

Es una pregunta retórica porque planeo presentar una propuesta como alternativa, que concebí durante el estudio de esta propuesta y considerando todos sus inconvenientes.

Pero me estoy desviando, eso vendrá más adelante y este comentario es sobre por qué la propuesta actual necesita ser reconsiderada.

Falta de apoyo declarado para break

Esto puede parecer que sale del campo izquierdo ya que la mayoría de las personas usan retornos anticipados para el manejo de errores, pero he descubierto que es preferible usar break para el manejo de errores que envuelve la mayor parte o la totalidad de una función antes de return .

He usado este enfoque durante un tiempo y sus beneficios para facilitar la refactorización solo lo hacen preferible a return temprano, pero tiene varios otros beneficios, incluido un punto de salida único y la capacidad de terminar una sección de una función antes pero aún ser Capaz de ejecutar la limpieza _ (que es probablemente la razón por la que rara vez uso defer , que me resulta más difícil razonar en términos de flujo del programa).

Para usar break en lugar del retorno anticipado, use un bucle for range "1" {...} para crear un bloque para que la ruptura salga de _ (de hecho, creo un paquete llamado only que solo contiene una constante llamado Once con un valor de "1" ):_

func (me *Config) WriteFile() (err error) {
    for range only.Once {
        var j []byte
        j, err = json.MarshalIndent(me, "", "    ")
        if err != nil {
            err = fmt.Errorf("unable to marshal config; %s", 
                err.Error(),
            )
            break
        }
        err = me.MaybeMakeDir(me.GetDir(), os.ModePerm)
        if err != nil {
            err = fmt.Errorf("unable to make directory'%s'; %s", 
                me.GetDir(), 
                err.Error(),
            )
            break
        }
        err = ioutil.WriteFile(string(me.GetFilepath()), j, os.ModePerm)
        if err != nil {
            err = fmt.Errorf("unable to write to config file '%s'; %s", 
                me.GetFilepath(), 
                err.Error(),
            )
            break
        }
    }
    return err
}

Planeo escribir un blog sobre el patrón en detalle en un futuro cercano, y discutir las diversas razones por las que he descubierto que funciona mejor que los retornos anticipados.

Pero yo divago. La razón por la que lo mencioné aquí es que Go implementaría un manejo de errores que asume return tempranos e ignora el uso break para el manejo de errores.

Mi opinión err == nil es problemática

Como digresión adicional, quiero mencionar la preocupación que he sentido sobre el manejo de errores idiomáticos en Go. Si bien creo firmemente en la filosofía de Go para manejar los errores cuando ocurren en lugar de usar el manejo de excepciones, siento que el uso de nil para indicar que no hay errores es problemático porque a menudo encuentro que me gustaría devolver un mensaje de éxito de una rutina, para usar en las respuestas de la API, y no solo devolver un valor no nulo solo cuando hay un error.

Entonces, para Go 2, realmente me gustaría ver que Go considere agregar un nuevo tipo integrado de status y tres funciones integradas iserror() , iswarning() , issuccess() . status podría implementar error , lo que permite mucha compatibilidad con versiones anteriores y un nil pasado a issuccess() devolvería true , pero status tendría un estado interno adicional para el nivel de error, de modo que la prueba del nivel de error siempre se realizaría con una de las funciones integradas e, idealmente, nunca con una verificación nil . Eso permitiría algo como el siguiente enfoque en su lugar:

func (me *Config) WriteFile() (sts status) {
    for range only.Once {
        var j []byte
        j, sts = json.MarshalIndent(me, "", "    ")
        if iserror(sts) {
            sts.AddMessage("unable to marshal config")
            break
        }
        sts = me.MaybeMakeDir(me.GetDir(), os.ModePerm)
        if iserror(sts) {
            sts.AddMessage("unable to make directory'%s'", me.GetDir())
            break
        }
        sts = ioutil.WriteFile(string(me.GetFilepath()), j, os.ModePerm)
        if iserror(sts) {
            sts.AddMessage("unable to write to config file '%s'", 
                me.GetFilepath(), 
            )
            break
        }
        sts = fmt.Status("config file written")
    }
    return sts
}

Ya estoy usando un enfoque de espacio de usuario en un paquete de uso interno actual de nivel pre-beta que es similar al anterior para el manejo de errores. Francamente , paso mucho menos tiempo pensando en cómo estructurar el código cuando utilizo este enfoque que cuando intentaba seguir el manejo idiomático de errores de Go.

Si cree que existe alguna posibilidad de que el código Go idiomático evolucione hacia este enfoque, tómelo en cuenta al implementar el manejo de errores, incluso al considerar esta propuesta try() .

_"No para todos"_ justificación

Una de las respuestas clave del equipo de Go ha sido _"Nuevamente, esta propuesta no intenta resolver todas las situaciones de manejo de errores"._
Y esa es probablemente la preocupación más preocupante, desde una perspectiva de gobernanza.

¿Este nuevo cambio complicado en el lenguaje que requerirá que todos aprendan los nuevos conceptos realmente aborda una cantidad convincente de casos de uso?

¿Y no es esa la misma justificación que los miembros del equipo central han negado numerosas solicitudes de funciones de la comunidad? La siguiente es una cita directa de un comentario realizado por un miembro del equipo de Go en una respuesta arquetípica a una solicitud de función enviada hace aproximadamente 2 años _ (no estoy nombrando a la persona o la solicitud de función específica porque esta discusión no debería poder la gente sino sobre el idioma):_

_"Una nueva característica del lenguaje necesita casos de uso convincentes. Todas las características del lenguaje son útiles, o nadie las propondría; la pregunta es: ¿son lo suficientemente útiles como para justificar complicar el lenguaje y requerir que todos aprendan los nuevos conceptos? ¿Cuáles son los usos convincentes? casos aquí? ¿Cómo la gente los usará? Por ejemplo, ¿la gente esperaría poder... y si es así, cómo lo harían? ¿Esta propuesta hace más que permitirle...?"_
— Un miembro central del equipo de Go

Francamente, cuando he visto esas respuestas, he sentido uno de dos sentimientos:

1. Indignación si es una característica con la que estoy de acuerdo, o
2. Elation si es una característica con la que no estoy de acuerdo.

Pero en cualquier caso, mis sentimientos eran/son irrelevantes; Entiendo y estoy de acuerdo en que parte de la razón por la que Go es el idioma en el que muchos de nosotros elegimos desarrollarnos es por esa celosa protección de la pureza del idioma.

Y es por eso que esta propuesta me preocupa tanto, porque el equipo central de Go parece estar profundizando en esta propuesta al mismo nivel que alguien que quiere dogmáticamente una característica esotérica que de ninguna manera la comunidad de Go tolerará.

_(Y realmente espero que el equipo no dispare al mensajero y tome esto como una crítica constructiva de alguien que quiere ver a Go seguir siendo lo mejor que puede ser para todos nosotros, ya que tendría que ser considerado "Persona non grata" por el equipo central.)_

Si exigir un conjunto convincente de casos de uso del mundo real es la barra para todas las propuestas de características generadas por la comunidad, ¿no debería ser también la misma barra para _todas_ las propuestas de características?

Anidamiento de try()

Esto también fue cubierto por algunos, pero quiero hacer una comparación entre try() y la solicitud continua de operadores ternarios. Citando los comentarios de otro miembro del equipo de Go hace unos 18 meses:

_"cuando se 'programa en grande' (bases de código grandes con equipos grandes durante largos períodos de tiempo), el código se lee MUCHO más a menudo de lo que se escribe, por lo que optimizamos la legibilidad, no la escritura"._

Una de las razones _principales_ declaradas para no agregar operadores ternarios es que son difíciles de leer y/o fáciles de leer mal cuando están anidados. Sin embargo, lo mismo puede ser cierto de declaraciones try() anidadas como try(try(try(to()).parse().this)).easily()) .

Razones adicionales para argumentar en contra de los operadores ternarios han sido que son _"expresiones"_ con el argumento de que las expresiones anidadas pueden agregar complejidad. ¿Pero try() crea también una expresión anidable?

Ahora alguien aquí dijo _"Creo que ejemplos como [ try() anidados] no son realistas"_ y esa declaración no fue cuestionada.

Pero si la gente acepta como postulado que los desarrolladores no anidarán try() entonces ¿por qué no se da la misma deferencia a los operadores ternarios cuando la gente dice _"Creo que los operadores ternarios profundamente anidados no son realistas?"_

En pocas palabras para este punto, creo que si el argumento en contra de los operadores ternarios es realmente válido, entonces también deberían considerarse argumentos válidos en contra de esta propuesta try() .

En resumen

En el momento de escribir esto, los 58% votos negativos contra 42% votos positivos. Creo que esto por sí solo debería ser suficiente para indicar que esta propuesta es lo suficientemente divisiva como para que sea hora de volver a la mesa de dibujo sobre este tema.

por favor

PD Para ponerlo más irónico, creo que deberíamos seguir la sabiduría parafraseada de Yoda:

_"No hay try() . Solo do() ."_

@ianlancetaylor

@beoran Quizás podría ampliar la conexión entre los genéricos y el manejo de errores.

No hablo por @beoran, pero en mi comentario de hace unos minutos verán que si tuviéramos genéricos _(más parámetros de retorno variados)_ entonces podríamos construir nuestro propio try() .

Sin embargo, y repetiré lo que dije anteriormente sobre los genéricos aquí, donde será más fácil de ver:

_"Creo que los casos de uso para los genéricos deberían reducirse agregando elementos integrados para abordar los casos de uso de los genéricos en lugar de agregar la confusa semántica y la sintaxis de los genéricos de Java et. al.)"_

@ianlancetaylor

Al tratar de formular una respuesta a su pregunta, traté de implementar la función try en Go tal como está y, para mi deleite, ya es posible emular algo bastante similar:

func try(v interface{}, err error) interface{} {
   if err != nil { 
     panic(err)
   }
   return v
}

Vea aquí cómo se puede usar: https://play.golang.org/p/Kq9Q0hZHlXL

Las desventajas de este enfoque son:

1. Se necesita un rescate diferido, pero con try como en esta propuesta, también se necesita un controlador diferido si queremos realizar un manejo de errores adecuado. Así que siento que esto no es un inconveniente serio. Incluso podría ser mejor si Go tuviera algún tipo de super(arg1, ..., argn) incorporado que haga que la persona que llama, un nivel más arriba en la pila de llamadas, regrese con los argumentos dados arg1,...argn, una especie de súper retorno Si tu quieres.
2. Este try que implementé solo puede funcionar con una función que devuelve un solo resultado y un error.
3. Debe escribir afirmar los resultados de la interfaz emtpy devueltos.

Los genéricos suficientemente potentes podrían resolver el problema 2 y 3, dejando solo 1, que podría resolverse agregando un super() . Con esas dos características en su lugar, podríamos obtener algo como:

func (T ... interface{})try(T, err error) super {
   if err != nil { 
      super(err)
   }
  super(T...)
}

Y entonces el rescate diferido ya no sería necesario. Este beneficio estaría disponible incluso si no se agregan genéricos a Go.

En realidad, esta idea de un super() incorporado es tan poderosa e interesante que podría publicar una propuesta por separado.

@beoran Es bueno ver que llegamos exactamente a las mismas restricciones de forma independiente con respecto a la implementación try() en el área de usuario, excepto por la parte superior que no incluí porque quería hablar sobre algo similar en una propuesta alternativa. :-)

Me gusta la propuesta, pero el hecho de que tuvieras que especificar explícitamente que defer try(...) y go try(...) no están permitidos me hizo pensar que algo no estaba del todo bien... La ortogonalidad es una buena guía de diseño. Al leer más y ver cosas como
x = try(foo(...)) y = try(bar(...))
¡Me pregunto si puede ser try necesita ser un contexto ! Considerar:
try ( x = foo(...) y = bar(...) )
Aquí foo() y bar() devuelven dos valores, el segundo de los cuales es error . Intente que la semántica solo importe para las llamadas dentro del bloque try donde el valor de error devuelto se omite (sin receptor) en lugar de ignorarlo (el receptor es _ ). Incluso puede manejar algunos errores entre llamadas foo y bar .

Resumen:
a) el problema de no permitir try por go y defer desaparece en virtud de la sintaxis.
b) el manejo de errores de múltiples funciones puede eliminarse.
c) su naturaleza mágica se expresa mejor como una sintaxis especial que como una llamada de función.

Si try es un contexto, acabamos de crear bloques try/catch que estamos tratando de evitar específicamente (y por una buena razón)

No hay trampa. Se generaría exactamente el mismo código que cuando la propuesta actual tiene
x = try(foo(...)) y = try(bar(...))
Esta es solo una sintaxis diferente, no semántica.
````

Supongo que hice algunas suposiciones al respecto que no debería haber hecho, aunque todavía tiene un par de inconvenientes.

¿Qué sucede si foo o bar no devuelven un error? ¿También se pueden colocar en el contexto de prueba? Si no, parece que sería un poco feo cambiar entre funciones de error y no error, y si pueden, entonces volvemos a los problemas de los bloques de prueba en lenguajes más antiguos.

Lo segundo es que, por lo general, la sintaxis keyword ( ... ) significa que antepone la palabra clave en cada línea. Entonces, para import, var, const, etc.: cada línea comienza con la palabra clave. Hacer una excepción a esa regla no parece una buena decisión

En lugar de usar una función, ¿sería más idiomático usar un identificador especial?

Ya tenemos el identificador en blanco _ que ignora los valores.
Podríamos tener algo como # que solo se puede usar en funciones que tienen el último valor devuelto de tipo error.

func foo() (error) {
    f, # := os.Open()
    defer f.Close()
    _, # = f.WriteString("foo")
    return nil
}

cuando se asigna un error a # la función regresa inmediatamente con el error recibido. En cuanto a las demás variables sus valores serían:

• si no se nombran valor cero
• el valor asignado a las variables nombradas de lo contrario

@deanveloper , la semántica del bloque try solo importa para las funciones que devuelven un valor de error y donde el valor de error no está asignado. Entonces, el último ejemplo de la presente propuesta también podría escribirse como
try(x = foo(...)) try(y = bar(...))
poner ambas sentencias dentro del mismo bloque es similar a lo que hacemos para las sentencias import , const y var repetidas.

Ahora si tienes, por ejemplo
try( x = foo(...)) go zee(...) defer fum() y = bar(...) )
Esto es equivalente a escribir
try(x = foo(...)) go zee(...) defer fum() try(y = bar(...))
Factorizar todo eso en un bloque de prueba lo hace menos ocupado.

Considerar
try(x = foo())
Si foo() no devuelve un valor de error, esto es equivalente a
x = foo()

Considerar
try(f, _ := os.open(filename))
Dado que se ignora el valor de error devuelto, esto es equivalente a solo
f, _ := os.open(filename)

Considerar
try(f, err := os.open(filename))
Dado que el valor de error devuelto no se ignora, esto es equivalente a
f, err := os.open(filename) if err != nil { return ..., err }
Como se especifica actualmente en la propuesta.

¡Y también ordena muy bien los intentos anidados!

Aquí hay un enlace a la propuesta alternativa que mencioné anteriormente:

• https://github.com/golang/go/issues/32473

Requiere agregar dos (2) funciones de lenguaje pequeñas pero de propósito general para abordar los mismos casos de uso que try()

1. Capacidad para llamar a un func /cierre en una instrucción de asignación.
2. Habilidad para break , continue o return más de un nivel.

Con estas dos características, no habría _"magia"_ y creo que su uso produciría un código Go que es más fácil de entender y más en línea con el código idiomático Go con el que todos estamos familiarizados.

He leído la propuesta y realmente me gusta a dónde va Try.

Dado lo frecuente que será el intento, me pregunto si convertirlo en un comportamiento más predeterminado lo haría más fácil de manejar.

Considere los mapas. Esto es válido:

v := m[key]

como es esto:

v, ok := m[key]

¿Qué pasa si manejamos los errores exactamente de la manera que sugiere try, pero eliminamos el incorporado. Así que si comenzamos con:

v, err := fn()

En lugar de escribir:

v := try(fn())

En su lugar, podríamos escribir:

v := fn()

Cuando el valor de err no se captura, se maneja exactamente como lo hace el intento. Tomaría un poco de tiempo acostumbrarse, pero se siente muy similar a v, ok := m[key] y v, ok := x.(string) . Básicamente, cualquier error no controlado hace que la función regrese y se establezca el valor err.

Para volver a las conclusiones de los documentos de diseño y los requisitos de implementación:

• Se conserva la sintaxis del idioma y no se introducen nuevas palabras clave
• Sigue siendo azúcar sintáctico como try y, con suerte, es fácil de explicar.
• No requiere nueva sintaxis
• Debe ser completamente compatible con versiones anteriores.

Me imagino que esto tendría casi los mismos requisitos de implementación que try, ya que la principal diferencia es que, en lugar de que el incorporado active el azúcar sintáctico, ahora es la ausencia del campo err.

Entonces, usando el ejemplo CopyFile de la propuesta junto con defer fmt.HandleErrorf(&err, "copy %s %s", src, dst) , obtenemos:

func CopyFile(src, dst string) (err error) {
        defer fmt.HandleErrorf(&err, "copy %s %s", src, dst)

        r := os.Open(src)
        defer r.Close()

        w := os.Create(dst)
        defer func() {
                err := w.Close()
                if err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        io.Copy(w, r)
        w.Close()
        return nil
}

@savaki Me gusta esto y estaba pensando en lo que se necesitaría para que Go cambie el manejo de errores al manejar siempre los errores de forma predeterminada y dejar que el programador especifique cuándo no hacerlo (capturando el error en una variable) pero falta total de cualquier El identificador haría que el código fuera difícil de seguir, ya que uno no podría ver todos los puntos de retorno. Puede haber una convención para nombrar funciones que podrían devolver un error de manera diferente (como usar mayúsculas en los identificadores públicos). Puede ser que si una función devuelve un error, siempre debe terminar con, digamos ? . Entonces, Go siempre podría manejar implícitamente el error y devolverlo automáticamente a la función de llamada, como intentarlo. Esto lo hace muy similar a algunas propuestas que sugieren usar un identificador ? en lugar de intentarlo, pero una diferencia importante es que aquí ? sería parte del nombre de la función y no un identificador adicional. De hecho, una función que devuelve error como el último valor devuelto ni siquiera se compilaría si no tuviera el sufijo ? . Por supuesto ? es arbitrario y podría reemplazarse con cualquier otra cosa que hiciera más explícita la intención. operation?() sería equivalente a envolver try(someFunc()) pero ? sería parte del nombre de la función y su único propósito sería indicar que la función puede devolver un error al igual que las mayúsculas la primera letra de una variable.

Superficialmente, esto termina siendo muy similar a otras propuestas que solicitan reemplazar try con ? pero una diferencia fundamental es que hace que el manejo de errores sea implícito (automático) y, en cambio, hace explícitos los errores de ignorar (o envolver) que una especie de mejor práctica de todos modos. El problema más obvio con esto, por supuesto, es que no es compatible con versiones anteriores y estoy seguro de que hay muchos más.

Dicho esto, estaría muy interesado en ver cómo Go puede hacer que el manejo de errores sea el caso predeterminado/implícito al automatizarlo y dejar que el programador escriba un poco de código adicional para ignorar/anular el manejo. Creo que el desafío es cómo hacer que todos los puntos de retorno sean obvios en este caso porque sin ellos los errores se volverán más como excepciones en el sentido de que podrían provenir de cualquier parte ya que el flujo del programa no lo haría obvio. Se podría decir que cometer errores implícitos con el indicador visual es lo mismo que implementar try y hacer que errcheck sea una falla del compilador.

¿podríamos hacer algo como las excepciones de C++ con decoradores para funciones antiguas?

func some_old_test() (int, error){
    return 0, errors.New("err1")
}
func some_new_test() (int){
        if true {
             return 1
        }
    throw errors.New("err2")
}
func throw_res(int, e error) int {
    if e != nil {
        throw e
    }
    return int
}
func main() {
    fmt.Println("Hello, playground")
    try{
        i := throw_res(some_old_test())
        fmt.Println("i=", i + some_new_test())
    } catch(err io.Error) {
        return err
    } catch(err error) {
        fmt.Println("unknown err", err)
    }
}

@owais Estaba pensando que la semántica sería exactamente la misma que intentar, por lo que al menos tendría que declarar el tipo de error. Así que si comenzamos con:

func foo() error {
  _, err := fn() 
  if err != nil {
    return err
  }

  return nil
} 

Si entiendo la propuesta de prueba, simplemente haciendo esto:

func foo() error {
  _  := fn() 
  return nil
} 

no compilaría. Una buena ventaja es que le da a la compilación la oportunidad de decirle al usuario lo que falta. Algo en el sentido de que usar el manejo implícito de errores requiere que se nombre el tipo de retorno de error, err.

Esto entonces, funcionaría:

func foo() (err error) {
  _  := fn() 
  return nil
} 

¿Por qué no simplemente manejar el caso de un error que no está asignado a una variable?

• elimine la necesidad de devoluciones con nombre, el compilador puede hacer todo esto por sí solo.
• permite añadir contexto.
• maneja el caso de uso común.
• compatible con versiones anteriores
• no interactúa extrañamente con aplazamiento, bucles o interruptores.

retorno implícito para el caso if err != nil, el compilador puede generar un nombre de variable local para retornos si es necesario, el programador no puede acceder.
personalmente no me gusta este caso particular desde el punto de vista de la legibilidad del código

f := os.Open("foo.txt")

prefiero un retorno explícito, sigue el código se lee más que el mantra escrito

f := os.Open("foo.txt") else return

Curiosamente, podríamos aceptar ambas formas y hacer que gofmt agregue automáticamente el retorno else.

agregando contexto, también denominación local de la variable. return se vuelve explícito porque queremos agregar contexto.

f := os.Open("foo.txt") else err {
  return errors.Wrap(err, "some context")
}

agregar contexto con múltiples valores de retorno

f := os.Open("foo.txt") else err {
  return i, j, errors.Wrap(err, "some context")
}

las funciones anidadas requieren que las funciones externas manejen todos los resultados en el mismo orden
menos el error final.

bits := ioutil.ReadAll(os.Open("foo")) else err {
  // either error ends up here.
  return i, j, errors.Wrap(err, "some context")
}

el compilador rechaza la compilación debido a que falta el valor de retorno de error en la función

func foo(s string) int {
   i := strconv.Atoi(s) // cannot implicitly return error due to missing error return value for foo.
   return i * 2
}

felizmente compila porque el error se ignora explícitamente.

func foo(s string) int {
   i, _ := strconv.Atoi(s)
   return i * 2
} 

el compilador está feliz. ignora el error como lo hace actualmente porque no se produce ninguna asignación o sufijo.

func foo() error {
  return errors.New("whoops")
}

func bar() {
  foo()
}

dentro de un ciclo puede usar continuar.

for _, s := range []string{"1","2","3","4","5","6"} {
  i := strconv.Atoi(s) else continue
}

editar: reemplazó ; con else

@savaki Creo que entendí su comentario original y me gusta la idea de que Go maneje los errores de forma predeterminada, pero no creo que sea viable sin agregar algunos cambios de sintaxis adicionales y, una vez que lo hagamos, se vuelve sorprendentemente similar a la propuesta actual.

El mayor inconveniente de lo que propones es que no expone todos los puntos desde donde una función puede devolver a diferencia del actual if err != nil {return err} o la función de prueba presentada en esta propuesta. Aunque funcionaría exactamente de la misma manera debajo del capó, visualmente el código se vería muy diferente. Al leer el código, no habría forma de saber qué llamadas de función podrían devolver un error. Eso terminaría siendo una experiencia peor que las excepciones en mi opinión.

Es posible que el manejo de errores se haga implícito si el compilador forzó alguna convención semántica en las funciones que podrían devolver errores. Al igual que deben comenzar o terminar con una determinada frase o carácter. Eso haría que todos los puntos de retorno fueran muy obvios y creo que sería mejor que el manejo manual de errores, pero no estoy seguro de cuán significativamente mejor teniendo en cuenta que ya hay controles de pelusa que gritan carga cuando detectan que se ignora un error. Sería muy interesante ver si el compilador puede forzar que las funciones sean nombradas de cierta manera dependiendo de si pueden devolver posibles errores.

El principal inconveniente de este enfoque es que se debe nombrar el parámetro de resultado del error, lo que posiblemente genere API menos bonitas (pero consulte las preguntas frecuentes sobre este tema). Creemos que nos acostumbraremos una vez que este estilo se haya consolidado.

No estoy seguro si algo como esto se ha sugerido antes, no puedo encontrarlo aquí o en la propuesta. ¿Ha considerado otra función integrada que devuelve un puntero al valor de retorno de error de la función actual?
p.ej:

func example() error {
        var err *error = funcerror() // always return a non-nil pointer
        fmt.Print(*err) // always nil if the return parameters are not named and not in a defer

        defer func() {
                err := funcerror()
                fmt.Print(*err) // "x"
        }

        return errors.New("x")
}

func exampleNamed() (err error) {
        funcErr := funcerror()
        fmt.Print(*funcErr) // "nil"

        err = errors.New("x")
        fmt.Print(*funcErr) // "x", named return parameter is reflected even before return is called

        *funcErr = errors.New("y")
        fmt.Print(err) // "y", unfortunate side effect?

        defer func() {
                funcErr := funcerror()
                fmt.Print(*funcErr) // "z"
                fmt.Print(err) // "z"
        }

        return errors.New("z")
}

uso con prueba:

func CopyFile(src, dst string) (error) {
        defer func() {
                err := funcerror()
                if *err != nil {
                        *err = fmt.Errorf("copy %s %s: %v", src, dst, err)
                }
        }()
        // one liner alternative
        // defer fmt.HandleErrorf(funcerror(), "copy %s %s", src, dst)

        r := try(os.Open(src))
        defer r.Close()

        w := try(os.Create(dst))
        defer func() {
                w.Close()
                err := funcerror()
                if *err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        try(io.Copy(w, r))
        try(w.Close())
        return nil
}

Alternativamente, funerrorr (el nombre es un trabajo en progreso: D) podría devolver nil si no se llama dentro de defer.

Otra alternativa es que funcror devuelva una interfaz de "Error" para que sea de solo lectura:

type interface Errorer() {
        Error() error
}

@savaki De hecho, me gusta su propuesta de omitir try() y permitir que sea más como probar un mapa o una afirmación de tipo. Eso se siente mucho más _"Go-like"._

Sin embargo, todavía veo un problema evidente, y es que su propuesta supone que todos los errores que usan este enfoque activarán un return y dejarán la función. Lo que no contempla es emitir un break de los for actuales ni un continue de los for actuales.

Los primeros return son un mazo cuando muchas veces un bisturí es la mejor opción.

Por lo tanto, afirmo que se debe permitir que break y continue sean estrategias válidas de manejo de errores y, actualmente, su propuesta supone solo return mientras que try() supone eso o llamar a un error controlador que en sí mismo solo puede return , no break o continue .

Parece que savaki y yo teníamos ideas similares, solo agregué la semántica de bloque para lidiar con el error si lo desea. Por ejemplo, agregando contexto, para bucles en los que desea cortocircuitar, etc.

@mikeschinkel ve mi extensión, él y yo teníamos ideas similares, simplemente la extendí con una declaración de bloque opcional

@james-lawrence

@mikesckinkel ve mi extensión, él y yo teníamos ideas similares, simplemente la extendí con una declaración de bloque opcional

Tomando tu ejemplo:

f := os.Open("foo.txt"); err {
  return errors.Wrap(err, "some context")
}

Que se compara con lo que hacemos hoy:

f,err := os.Open("foo.txt"); 
if err != nil {
  return errors.Wrap(err, "some context")
}

Definitivamente es preferible para mí. Excepto que tiene algunos problemas:

1. err parece estar _"mágicamente"_ declarado. La magia debe minimizarse, ¿no? Así que vamos a declararlo:

f, err := os.Open("foo.txt"); err {
  return errors.Wrap(err, "some context")
}

1. Pero eso todavía no funciona porque Go no interpreta los valores de nil como false ni los valores de puntero como true , por lo que tendría que ser:

f, err := os.Open("foo.txt"); err != nil {
  return errors.Wrap(err, "some context")
}

Y lo que eso funciona, comienza a parecer mucho trabajo y mucha sintaxis en una línea, así que podría continuar haciendo lo antiguo para mayor claridad.

Pero, ¿y si Go agregara dos (2) funciones integradas? iserror() y error() ? Entonces podríamos hacer esto, que no me parece tan malo:

f := os.Open("foo.txt"); iserror() {
  return errors.Wrap(error(), "some context")
}

O mejor _(algo así como):_

f := os.Open("foo.txt"); iserror() {
  return error().Extend("some context")
}

¿Qué piensas tú y los demás?

Aparte, revisa la ortografía de mi nombre de usuario. No me habrían notificado de tu mención si no hubiera estado prestando atención de todos modos...

@mikeschinkel lo siento por el nombre que estaba en mi teléfono y github no estaba sugiriendo automáticamente.

err parece estar declarado "mágicamente". La magia debe minimizarse, ¿no? Así que vamos a declararlo:

meh, toda la idea de insertar automáticamente un retorno es mágica. esto no es lo más mágico que sucede en toda esta propuesta. Además, diría que se declaró el error; justo al final dentro del contexto de un bloque con ámbito, lo que evita que contamine el ámbito principal y, al mismo tiempo, mantenga todas las cosas buenas que obtenemos normalmente con el uso de declaraciones if.

En general, estoy bastante contento con el manejo de errores de go con las próximas adiciones al paquete de errores. No veo nada en esta propuesta como muy útil. Solo estoy tratando de ofrecer el ajuste más natural para el objetivo si estamos decididos a hacerlo.

_"Toda la idea de insertar automáticamente una devolución es mágica"._

No obtendrás ningún argumento de mí allí.

_"Esto no es lo más mágico que está pasando en toda esta propuesta"._

Supongo que estaba tratando de argumentar que _"toda la magia es problemática"._

_"Además, diría que se declaró el error; justo al final dentro del contexto de un bloque con ámbito..."_

Entonces, si quisiera llamarlo err2 ¿esto también funcionaría?

f := os.Open("foo.txt"); err2 {
  return errors.Wrap(err, "some context")
}

Así que asumo que también está proponiendo un manejo especial de casos de err / err2 después del punto y coma, es decir, que se supondría que es nil o no nil en lugar de bool como cuando miras un mapa?

if _,ok := m[a]; !ok {
   print("there is no 'a' in 'm'")
}

En general, estoy bastante contento con el manejo de errores de go con las próximas adiciones al paquete de errores.

Yo también estoy contento con el manejo de errores, cuando se combina con break y continue _(pero no return .)_

Tal como está, veo esta propuesta try() como más dañina que útil, y preferiría no ver nada antes que esta implementación según lo propuesto. #jmtcw.

@beoran @mikeschinkel Anteriormente sugerí que no podíamos implementar esta versión de try usando genéricos, porque cambia el flujo de control. Si estoy leyendo correctamente, ambos están sugiriendo que podríamos usar genéricos para implementar try haciendo que llame a panic . Pero esta versión de try muy explícitamente no panic . Por lo tanto, no podemos usar genéricos para implementar esta versión de try .

Sí, podríamos usar genéricos (una versión de genéricos significativamente más poderosa que la del borrador de diseño en https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md) para escribir una función. que entra en pánico ante el error. Pero entrar en pánico ante un error no es el tipo de manejo de errores que los programadores de Go escriben hoy, y no me parece una buena idea.

El manejo especial de @mikeschinkel sería que el bloque se ejecuta solo cuando hay un error.
```
f := os.Open('foo'); err { return err } // err siempre sería no-nil aquí.

@ianlancetaylor

_"Sí, podríamos usar genéricos... Pero entrar en pánico ante un error no es el tipo de manejo de errores que los programadores de Go escriben hoy, y no me parece una buena idea"._

De hecho, estoy muy de acuerdo con usted en esto, por lo que parece que puede haber malinterpretado la intención de mi comentario. No estaba sugiriendo en absoluto que el equipo de Go implementaría un manejo de errores que usaba panic() , por supuesto que no.

En cambio, estaba tratando de seguir su ejemplo de muchos de sus comentarios anteriores sobre otros problemas y sugerí que evitemos hacer cambios en Go que no sean absolutamente necesarios porque, en cambio, son posibles en el espacio del usuario . Entonces, _si_ se abordaran los genéricos _entonces_ las personas que querrían try() podrían implementarlo ellos mismos, aunque aprovechando panic() . Y esa sería una característica menos que el equipo necesitaría agregar y documentar para Go.

Lo que no estaba haciendo, y tal vez eso no estaba claro, era recomendar que las personas realmente usen panic() para implementar try() , solo que podrían hacerlo si realmente quisieran, y tenían las características de genéricos.

¿Eso aclara?

Para mí, llamar a panic , como sea que se haga, es bastante diferente de esta propuesta para try . Entonces, aunque creo que entiendo lo que dices, no estoy de acuerdo en que sean equivalentes. Incluso si tuviéramos genéricos lo suficientemente potentes como para implementar una versión de try que entre en pánico, creo que todavía habría un deseo razonable por la versión de try presentada en esta propuesta.

@ianlancetaylor Reconocido. Nuevamente, estaba buscando una razón por la que try() no necesitaría agregarse en lugar de encontrar una manera de agregarlo. Como dije anteriormente, preferiría no tener nada nuevo para el manejo de errores que tener try() como se propone aquí.

Personalmente, me gustó más la propuesta anterior check que esta, basada en aspectos puramente visuales; check tenía el mismo poder que este try() pero bar(check foo()) es más legible para mí que bar(try(foo())) (¡solo necesitaba un segundo para contar los paréntesis!).

Más importante aún, mi principal queja sobre handle / check era que no permitía envolver cheques individuales de diferentes maneras, y ahora esta propuesta try() tiene el mismo defecto, mientras invoca características engañosas raramente utilizadas que confunden a los novatos de diferidos y devoluciones con nombre. Y con handle al menos teníamos la opción de usar ámbitos para definir bloques de control, con defer incluso eso no es posible.

En lo que a mí respecta, esta propuesta pierde frente a la propuesta anterior handle / check en todos los aspectos.

Aquí hay otra preocupación con el uso de diferidos para el manejo de errores.

try es una salida controlada/intencionada de una función. aplaza la ejecución siempre, incluidas las salidas no controladas/involuntarias de las funciones. Ese desajuste podría causar confusión. He aquí un escenario imaginario:

func someHTTPHandlerGuts() (err error) {
  defer func() {
    recordMetric("db call failed")
    return fmt.HandleErrorf("db unavailable: %v", err)
  }()
  data := try(makeDBCall)
  // some code that panics due to a bug
  return nil
}

Recuerde que net/http se recupera de pánicos e imagine depurar un problema de producción en torno al pánico. Vería su instrumentación y vería un aumento en las fallas de llamadas a la base de datos, de las llamadas recordMetric . Esto podría enmascarar el verdadero problema, que es el pánico en la siguiente línea.

No estoy seguro de cuán grave es esta preocupación en la práctica, pero (lamentablemente) quizás sea otra razón para pensar que el aplazamiento no es un mecanismo ideal para el manejo de errores.

Aquí hay una modificación que puede ayudar con algunas de las inquietudes planteadas: trate try como goto en lugar de como return . Escúchame. :)

try sería azúcar sintáctico para:

t1, … tn, te := f()  // t1, … tn, te are local (invisible) temporaries
if te != nil {
        err = te   // assign te to the error result parameter
        goto error // goto "error" label
}
x1, … xn = t1, … tn  // assignment only if there was no error

Beneficios:

• No se requiere defer para decorar errores. (Sin embargo, aún se requieren devoluciones con nombre).
• La existencia de la etiqueta error: es una pista visual de que hay un try en algún lugar de la función.

Esto también proporciona un mecanismo para agregar controladores que elude los problemas del controlador como función: use etiquetas como controladores. try(fn(), wrap) sería goto wrap en lugar de goto error . El compilador puede confirmar que wrap: está presente en la función. Tenga en cuenta que tener controladores también ayuda con la depuración: puede agregar/modificar el controlador para proporcionar una ruta de depuración.

Código de muestra:

func CopyFile(src, dst string) (err error) {
    r := try(os.Open(src))
    defer r.Close()

    w := try(os.Create(dst))
    defer func() {
        w.Close()
        if err != nil {
            os.Remove(dst) // only if a “try” fails
        }
    }()

    try(io.Copy(w, r), copyfail)
    try(w.Close())
    return nil

error:
    return fmt.Errorf("copy %s %s: %v", src, dst, err)

copyfail:
    recordMetric("copy failure") // count incidents of this failure
    return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

Otros comentarios:

• Es posible que deseemos exigir que cualquier etiqueta utilizada como destino de un try esté precedida por una declaración de terminación. En la práctica, esto los obligaría al final de la función y podría evitar algún código de espagueti. Por otro lado, podría impedir algunos usos razonables y útiles.
• try podría usarse para crear un bucle. Creo que esto cae bajo el lema de "si duele, no lo hagas", pero no estoy seguro.
• Esto requeriría arreglar https://github.com/golang/go/issues/26058.

Crédito: Creo que una variante de esta idea fue sugerida por primera vez por @griesemer en persona en GopherCon el año pasado.

@josharian Pensar en la interacción con panic es importante aquí, y me alegro de que lo hayas mencionado, pero tu ejemplo me parece extraño. En el siguiente código, no tiene sentido para mí que el aplazamiento siempre registre una métrica "db call failed" . Sería una métrica falsa si someHTTPHandlerGuts tiene éxito y devuelve nil . El defer se ejecuta en todos los casos de salida, no solo en los casos de error o pánico, por lo que el código parece incorrecto incluso si no hay pánico.

func someHTTPHandlerGuts() (err error) {
  defer func() {
    recordMetric("db call failed")
    return fmt.HandleErrorf("db unavailable: %v", err)
  }()
  data := try(makeDBCall)
  // some code that panics due to a bug
  return nil
}

@josharian Sí, esta es más o menos exactamente la versión que discutimos el año pasado (excepto que usamos check en lugar de try ). Creo que sería crucial que uno no pudiera saltar "hacia atrás" al resto del cuerpo de la función, una vez que estemos en la etiqueta error . Eso aseguraría que el goto esté algo "estructurado" (no es posible un código de espagueti). Una preocupación que surgió fue que la etiqueta del controlador de errores (la error: ) siempre terminaría al final de la función (de lo contrario, habría que sortearla de alguna manera). Personalmente, me gusta que el código de manejo de errores esté fuera del camino (al final), pero otros sintieron que debería ser visible desde el principio.

@mikeshenkel Veo regresar de un bucle como una ventaja en lugar de una negativa. Supongo que eso alentaría a los desarrolladores a usar una función separada para manejar el contenido de un bucle o usar explícitamente err como lo hacemos actualmente. Ambos me parecen buenos resultados.

Desde mi punto de vista, no siento que esta sintaxis de prueba tenga que manejar cada caso de uso al igual que no siento que deba usar el

V, vale:= m[clave]

Formulario a partir de la lectura de un mapa

Puede evitar que las etiquetas Goto obliguen a los controladores a finalizar la función al resucitar la propuesta handle / check en una forma simplificada. ¿Qué pasa si usamos la sintaxis handle err { ... } pero no permitimos que los controladores se encadenen, sino que solo se usa el último? Simplifica mucho esa propuesta y es muy similar a la idea de ir a, excepto que acerca el manejo al punto de uso.

func CopyFile(src, dst string) (err error) {
    handle err {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
    r := check os.Open(src)
    defer r.Close()

    w := check os.Create(dst)
    defer func() {
        w.Close()
        if err != nil {
            os.Remove(dst) // only if a “check” fails
        }
    }()

    {
        // handlers are scoped, after this scope the original handle is used again.
        // as an alternative, we could have repeated the first handle after the io.Copy,
        // or come up with a syntax to name the handlers, though that's often not useful.
        handle err {
            recordMetric("copy failure") // count incidents of this failure
            return fmt.Errorf("copy %s %s: %v", src, dst, err)
        }
        check io.Copy(w, r)
    }
    check w.Close()
    return nil
}

Como beneficio adicional, esto tiene un camino futuro para permitir que los controladores se encadenen, ya que todos los usos existentes tendrían un retorno.

@josharian @griesemer si introduce controladores con nombre (que muchas respuestas para verificar/manejar solicitan, ver temas recurrentes ), hay opciones de sintaxis preferibles a try(f(), err) :

try.err f()
try?err f()
try#err f()

?err    f() // because 'try' is redundant
?return f() // no handler
?panic  f() // no handler

(?err f()).method()

f?err() // lead with function name, instead of error handling
f?err().method()

file, ?err := os.Open(...) // many check/handle responses also requested this style

Una de las cosas que más me gustan de Go es que su sintaxis está relativamente libre de puntuación y se puede leer en voz alta sin mayores problemas. Realmente odiaría que Go terminara como $#@!perl .

Para mí, hacer "probar" una función integrada y habilitar cadenas tiene 2 problemas:

• Es inconsistente con el resto del flujo de control en go (por ejemplo, palabras clave for/if/return/etc).
• Hace que el código sea menos legible.

Preferiría hacerlo una declaración sin paréntesis. Los ejemplos de la propuesta requerirían varias líneas, pero serían más legibles (es decir, sería más difícil pasar por alto las instancias de "prueba" individuales). Sí, rompería los analizadores externos, pero prefiero preservar la coherencia.

El operador ternario es otro lugar donde ir no tiene nada y requiere más pulsaciones de teclas pero al mismo tiempo mejora la legibilidad/mantenibilidad. Agregar "probar" en esta forma más restringida equilibrará mejor la expresividad frente a la legibilidad, en mi opinión.

FWIW, panic afecta el flujo de control y tiene paréntesis, pero go y defer también afectan el flujo y no. Tiendo a pensar que try es más similar a defer en que es una operación de flujo inusual y que hace que sea más difícil de hacer try (try os.Open(file)).Read(buf) es bueno porque queremos desalentar las frases ingeniosas de todos modos, pero lo que sea. Cualquiera esta bien.

Sugerencia que todos odiarán por un nombre implícito para una variable de retorno de error final: $err . Es mejor que try() mi opinión. :-)

@griesemer

_"Personalmente, me gusta el código de manejo de errores fuera del camino (al final)"_

+1 a eso!

Encuentro que el manejo de errores implementado _antes_ de que ocurra el error es mucho más difícil de razonar que el manejo de errores implementado _después_ de que ocurra el error. Tener que retroceder mentalmente y obligarme a seguir el flujo lógico se siente como si estuviera en 1980 escribiendo Basic con GOTO.

Permítanme proponer otra forma potencial de manejar los errores usando CopyFile() como ejemplo nuevamente:

func CopyFile(src, dst string) (err error) {

    r := os.Open(src)
    defer r.Close()

    w := os.Create(dst)
    defer w.Close()

    io.Copy(w, r)
    w.Close()

    for err := error {
        switch err.Source() {
        case w.Close:
            os.Remove(dst) // only if a “try” fails
            fallthrough
        case os.Open, os.Create, io.Copy:
            err = fmt.Errorf("copy %s %s: %v", src, dst, err)
        default:
            err = fmt.Errorf("an unexpected error occurred")
        }
    }

    return err
}

Los cambios de idioma requeridos serían:

1. Permitir una construcción for error{} , similar a for range{} pero solo ingresada en caso de error y solo ejecutada una vez.

2. Permitir omitir la captura de valores devueltos que implementan <object>.Error() string pero solo cuando existe una construcción for error{} dentro del mismo func .

3. Hace que el flujo de control del programa salte a la primera línea de la construcción for error{} cuando un func devuelve un _"error"_ en su último valor de retorno.

4. Al devolver un _"error"_ Go agregaría asignar una referencia a la función que devolvió el error que debería ser recuperable por <error>.Source()

¿Qué es un _"error"_?

Actualmente, un _"error"_ se define como cualquier objeto que implementa Error() string y, por supuesto, no es nil .

Sin embargo, a menudo existe la necesidad de extender el error _incluso en caso de éxito_ para permitir la devolución de los valores necesarios para los resultados de éxito de una API RESTful. Por lo tanto, le pediría al equipo de Go que no asuma automáticamente que err!=nil significa _"error"_, sino que verifique si un objeto de error implementa un IsError() y si IsError() devuelve true antes de asumir que cualquier valor que no sea nil es un _"error"._

_(No estoy hablando necesariamente del código en la biblioteca estándar, pero principalmente si elige que su flujo de control se bifurque en un _"error"_. Si solo observa err!=nil , estaremos muy limitados en lo que puede hacer en términos de valores devueltos en nuestras funciones.)_

Por cierto, permitir que todos prueben un _"error"_ de la misma manera probablemente podría hacerse más fácilmente agregando una nueva función incorporada iserror() :

type ErrorIser interface {
    IsError() bool
}
func iserror(err error) bool {
    if err == nil { 
        return false
    }
    if _,ok := err.(ErrorIser); !ok {
        return true
    }
    return err.IsError()
}

Un lado se beneficia de permitir la no captura de _"errores"_

Tenga en cuenta que permitir que no se capture el último _"error"_ de las llamadas func permitiría una refactorización posterior para devolver errores de func que inicialmente no necesitaban devolver errores. Y permitiría esta refactorización sin romper ningún código existente que use esta forma de recuperación de errores y llame a dichos func s.

Para mí, esa decisión de _"¿Debería devolver un error o renunciar al manejo de errores por simplicidad en las llamadas?"_ es uno de mis mayores dilemas al escribir código Go. Permitir que no se capturen los _"errores"_ anteriores eliminaría prácticamente ese dilema.

De hecho, traté de implementar esta idea como traductor de Go hace aproximadamente medio año. No tengo una opinión firme sobre si esta característica debería agregarse como parte integrada de Go, pero permítanme compartir la experiencia (aunque no estoy seguro de que sea útil).

https://github.com/rhysd/trygo

Llamé al lenguaje extendido TryGo e implementé el traductor TryGo to Go.

Con el traductor, el código

func CreateFileInSubdir(subdir, filename string, content []byte) error {
    cwd := try(os.Getwd())

    try(os.Mkdir(filepath.Join(cwd, subdir)))

    p := filepath.Join(cwd, subdir, filename)
    f := try(os.Create(p))
    defer f.Close()

    try(f.Write(content))

    fmt.Println("Created:", p)
    return nil
}

se puede traducir a

func CreateFileInSubdir(subdir, filename string, content []byte) error {
    cwd, _err0 := os.Getwd()
    if _err0 != nil {
        return _err0
    }

    if _err1 := os.Mkdir(filepath.Join(cwd, subdir)); _err1 != nil {
        return _err1
    }

    p := filepath.Join(cwd, subdir, filename)
    f, _err2 := os.Create(p)
    if _err2 != nil {
        return _err2
    }
    defer f.Close()

    if _, _err3 := f.Write(content); _err3 != nil {
        return _err3
    }

    fmt.Println("Created:", p)
    return nil
}

Por la restricción del idioma, no pude implementar la llamada genérica try() . esta restringida a

• RHS de declaración de definición
• RHS de declaración de asignación
• Declaración de llamada

pero podría probar esto con mi pequeño proyecto. mi experiencia fue

• básicamente funciona bien y ahorra varias líneas
• el valor de retorno nombrado es en realidad inutilizable para err ya que el valor de retorno de su función está determinado tanto por la asignación como por la función especial try() . muy confuso
• esta función try() carecía de la función de 'error de ajuste' como se mencionó anteriormente.

_"Ambos me parecen buenos resultados"._

Tendremos que estar de acuerdo en estar en desacuerdo aquí.

_"esta sintaxis de prueba (no tiene que) manejar todos los casos de uso"_

Ese meme es probablemente el más preocupante. Al menos teniendo en cuenta lo resistente que ha sido el equipo/comunidad de Go a cualquier cambio en el pasado que no sea ampliamente aplicable.

Si permitimos esa justificación aquí, ¿por qué no podemos revisar propuestas anteriores que han sido rechazadas porque no eran ampliamente aplicables?

¿Y ahora estamos abiertos a abogar por cambios en Go que solo sean útiles para casos extremos seleccionados?

Supongo que establecer este precedente no producirá buenos resultados a largo plazo...

_"@mikeshenkel"_

PD No vi tu mensaje al principio por falta de ortografía. _(esto no me ofende, simplemente no me notifican cuando mi nombre de usuario está mal escrito...)_

Agradezco el compromiso con la compatibilidad con versiones anteriores que lo motiva a hacer de try una palabra clave incorporada, en lugar de una palabra clave, pero después de luchar con la absoluta _rareza_ de tener una función de uso frecuente que puede cambiar el flujo de control ( panic y recover son extremadamente raros), comencé a preguntarme: ¿alguien ha realizado algún análisis a gran escala de la frecuencia de try como identificador en bases de código de código abierto? Tenía curiosidad y escepticismo, así que hice una búsqueda preliminar en lo siguiente:

• https://github.com/google/go-github
• https://github.com/cucarachadb/cucaracha
• https://github.com/golang/net
• https://github.com/ejercismo/xgo
• https://github.com/GoogleCloudPlatform/kubernetes
• https://github.com/syncthing/syncthing
• https://github.com/mitchellh/packer
• https://github.com/drone/drone
• https://github.com/coreos/etcd
• https://github.com/docker/docker
• https://github.com/sjwhitworth/golearn
• https://github.com/bitly/nsq
• https://github.com/smartystreets/goconvey
• https://github.com/golang/herramientas
• https://github.com/coreos/fleet
• https://github.com/limetext/lima
• https://github.com/flynn/flynn
• https://github.com/dropbox/godropbox
• https://github.com/hashicorp/cónsul
• https://github.com/hashicorp/terraform

En las 11 108 770 líneas significativas de Go que viven en estos repositorios, solo se usaron 63 instancias de try como identificador. Por supuesto, me doy cuenta de que estas bases de código (si bien son grandes, ampliamente utilizadas e importantes por derecho propio) representan solo una fracción del código Go que existe y, además, no tenemos forma de analizar directamente las bases de código privadas, pero ciertamente es un resultado interesante

Además, debido a que try , como cualquier palabra clave, está en minúsculas, nunca la encontrará en la API pública de un paquete. Las adiciones de palabras clave solo afectarán las partes internas del paquete.

Todo esto es un prefacio de algunas ideas que quería incluir en la combinación que se beneficiaría de try como palabra clave.

Yo propondría las siguientes construcciones.

1) Sin controlador

// The existing proposal, but as a keyword rather than builtin.  When an error is 
// "caught", the function returns all zero values plus the error.  Nothing 
// particularly new here.
func doSomething() (int, error) {
    try SomeFunc()
    a, b := try AnotherFunc()

    // ...

    return 123, nil
}

2) Manejador

Tenga en cuenta que los controladores de errores son bloques de código simples, destinados a estar en línea, en lugar de funciones. Más sobre esto a continuación.

func doSomething() (int, error) {
    // Inline error handler
    a, b := try SomeFunc() else err {
        return 0, errors.Wrap(err, "error in doSomething:")
    }

    // Named error handlers
    handler logAndContinue err {
        log.Errorf("non-critical error: %v", err)
    }
    handler annotateAndReturn err {
        return 0, errors.Wrap(err, "error in doSomething:")
    }

    c, d := try SomeFunc() else logAndContinue
    e, f := try OtherFunc() else annotateAndReturn

    // ...

    return 123, nil
}

Restricciones propuestas:

• Solo puede try una llamada de función. No try err .
• Si no especifica un controlador, solo puede try desde dentro de una función que devuelve un error como su valor de retorno más a la derecha. No hay cambios en el comportamiento try según su contexto. Nunca entra en pánico (como se discutió mucho antes en el hilo).
• No hay "cadena de manejadores" de ningún tipo. Los controladores son solo bloques de código en línea.

Beneficios:

• La sintaxis try / else podría reducirse trivialmente al "compuesto si" existente:
  go a, b := try SomeFunc() else err { return 0, errors.Wrap(err, "error in doSomething:") }
  se convierte
  go if a, b, err := SomeFunc(); err != nil { return 0, errors.Wrap(err, "error in doSomething:") }
  En mi opinión, los condicionales siempre me han parecido más confusos que útiles por una razón muy simple: los condicionales generalmente ocurren _después_ de una operación, y tienen algo que ver con el procesamiento de sus resultados. Si la operación está encajada dentro de la declaración condicional, simplemente es menos obvio que está sucediendo. El ojo está distraído. Además, el alcance de las variables definidas no es tan obvio como cuando se encuentran en el extremo izquierdo de una línea.
• Los controladores de errores no se definen intencionalmente como funciones (ni con nada parecido a la semántica de funciones). Esto hace varias cosas por nosotros:
  
  
  
  • El compilador puede simplemente alinear un controlador con nombre donde sea que se haga referencia. Es mucho más como una simple plantilla macro/codegen que una llamada de función. El tiempo de ejecución ni siquiera necesita saber que existen controladores.
  
  
  • No estamos limitados con respecto a lo que podemos hacer dentro de un controlador. Evitamos las críticas de check / handle que "este marco de manejo de errores solo es bueno para rescates". También sorteamos la crítica de la "cadena de manejadores". Cualquier código arbitrario se puede colocar dentro de uno de estos controladores y no se implica ningún otro flujo de control.
  
  
  • No tenemos que secuestrar return dentro del controlador para que signifique super return . Secuestrar una palabra clave es extremadamente confuso. return solo significa return , y no hay una necesidad real de super return .
  
  
  • defer no necesita luz de luna como mecanismo de manejo de errores. Podemos seguir pensando en ello principalmente como una forma de limpiar los recursos, etc.
  
  
• Con respecto a agregar contexto a los errores:
  
  
  
  • Agregar contexto con controladores es extremadamente simple y se ve muy similar a los bloques if err != nil existentes
  
  
  • Aunque la construcción "probar sin controlador" no fomenta directamente la adición de contexto, es muy sencillo refactorizar en el formulario del controlador. Su uso previsto sería principalmente durante el desarrollo, y sería extremadamente sencillo escribir una verificación de go vet para resaltar los errores no controlados.
  
  

Disculpas si estas ideas son muy similares a otras propuestas. He tratado de mantenerme al día con todas ellas, pero es posible que me haya perdido una buena parte.

@brynbellomy Gracias por el análisis de palabras clave; es información muy útil. Parece que try como palabra clave podría estar bien. (Usted dice que las API no se ven afectadas; eso es cierto, pero try aún podría aparecer como nombre de parámetro o similar, por lo que es posible que la documentación tenga que cambiar. Pero estoy de acuerdo en que eso no afectaría a los clientes de esos paquetes).

Con respecto a su propuesta: estaría bien incluso sin controladores designados, ¿no es así? (Eso simplificaría la propuesta sin pérdida de potencia. Uno podría simplemente llamar a una función local desde el controlador en línea).

Con respecto a su propuesta: estaría bien incluso sin controladores designados, ¿no es así? (Eso simplificaría la propuesta sin pérdida de potencia. Uno podría simplemente llamar a una función local desde el controlador en línea).

@griesemer De hecho, me sentía bastante tibio al incluirlos. Ciertamente más Go-ish sin.

Por otro lado, parece que la gente quiere la capacidad de manejar errores de una sola línea, incluidas las frases de una sola línea que return . Un caso típico sería log, luego return . Si pagamos a una función local en la cláusula else , probablemente perdamos eso:

a, b := try SomeFunc() else err {
    someLocalFunc(err)
    return 0, err
}

(Sin embargo, todavía prefiero esto a los condicionales compuestos)

Sin embargo, aún podría obtener devoluciones de una sola línea que agreguen contexto de error al implementar un ajuste simple gofmt discutido anteriormente en el hilo:

a, b := try SomeFunc() else err { return 0, errors.Wrap(err, "bad stuff!") }

¿Es necesaria la nueva palabra clave en la propuesta anterior? Por qué no:

SomeFunc() else return
a, b := SomeOtherFunc() else err { return 0, errors.Wrap(err, "bad stuff!") }

@griesemer si los manejadores están nuevamente sobre la mesa, le sugiero que haga un nuevo problema para discutir sobre probar/manejar o probar/_etiqueta_. Esta propuesta omitió específicamente los controladores, y hay innumerables formas de definirlos e invocarlos.

Cualquier persona que sugiera controladores debe leer primero la wiki de comentarios de control/control. Es muy probable que lo que sea que sueñes ya esté descrito allí :-)
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback

@smonkewitz no, no es necesaria una nueva palabra clave en esa versión, ya que está vinculada a las declaraciones de asignación, que se ha mencionado varias veces hasta ahora en varios azúcares de sintaxis.

https://github.com/golang/go/issues/32437#issuecomment-499808741
https://github.com/golang/go/issues/32437#issuecomment-499852124
https://github.com/golang/go/issues/32437#issuecomment-500095505

@ianlancetaylor , ¿el equipo go ya ha considerado este tipo particular de manejo de errores? No es tan fácil de implementar como el intento incorporado propuesto, pero se siente más idiomático. ~Declaración innecesaria, lo siento.~

Me gustaría repetir algo que @deanveloper y algunos otros han dicho, pero con mi propio énfasis. En https://github.com/golang/go/issues/32437#issuecomment -498939499 @deanveloper dijo:

try es una devolución condicional. El flujo de control Y los retornos se sostienen sobre pedestales en Go. Todo el flujo de control dentro de una función está sangrado y todos los retornos comienzan con return . La combinación de estos dos conceptos en una llamada de función fácil de perder se siente un poco fuera de lugar.

Además, en esta propuesta try es una función que devuelve valores, por lo que puede usarse como parte de una expresión más grande.

Algunos han argumentado que panic ya sentó el precedente para una función incorporada que cambia el flujo de control, pero creo que panic es fundamentalmente diferente por dos razones:

1. El pánico no es condicional; siempre aborta la función de llamada.
2. Panic no devuelve ningún valor y, por lo tanto, solo puede aparecer como una declaración independiente, lo que aumenta su visibilidad.

Prueba por otro lado:

1. es condicional; puede o no regresar de la función de llamada.
2. Devuelve valores y puede aparecer en una expresión compuesta, posiblemente varias veces, en una sola línea, posiblemente más allá del margen derecho de la ventana de mi editor.

Por estas razones, creo que try se siente más que un "bit off", creo que fundamentalmente daña la legibilidad del código.

Hoy, cuando nos encontramos con algún código Go por primera vez, podemos hojearlo rápidamente para encontrar los posibles puntos de salida y los puntos de flujo de control. Creo que es una propiedad muy valiosa del código Go. Usando try se vuelve demasiado fácil escribir código que carece de esa propiedad.

Admito que es probable que los desarrolladores de Go que valoran la legibilidad del código converjan en modismos de uso por try que evitan estos problemas de legibilidad. Espero que eso suceda, ya que la legibilidad del código parece ser un valor central para muchos desarrolladores de Go. Pero no es obvio para mí que try agregue suficiente valor sobre los modismos de código existentes para soportar el peso de agregar un nuevo concepto al lenguaje para que todos lo aprendan y eso puede dañar fácilmente la legibilidad.

````
si != "rompió" {
no lo arregles
}

@ChrisHines A su punto (que se repite en otra parte de este hilo), agreguemos otra restricción:

• cualquier declaración try (incluso aquellas sin un controlador) debe ocurrir en su propia línea.

Aún se beneficiaría de una gran reducción en el ruido visual. Luego, tiene rendimientos garantizados anotados por return y rendimientos condicionales anotados por try , y esas palabras clave siempre se encuentran al principio de una línea (o, en el peor de los casos, directamente después de una asignación de variable).

Así que nada de este tipo de tonterías:

try EmitEvent(try (try DecodeMsg(m)).SaveToDB())

sino mas bien esto:

dm := try DecodeMsg(m)
um := try dm.SaveToDB()
try EmitEvent(um)

que todavía se siente más claro que esto:

dm, err := DecodeMsg(m)
if err != nil {
    return nil, err
}

um, err := dm.SaveToDB()
if err != nil {
    return nil, err
}

err = EmitEvent(um)
if err != nil {
    return nil, err
}

Una cosa que me gusta de este diseño es que es imposible ignorar silenciosamente los errores sin anotar que podría ocurrir uno . Mientras que en este momento, a veces ves x, _ := SomeFunc() (¿cuál es el valor de retorno ignorado? ¿un error? ¿algo más?), ahora tienes que anotar claramente:

x := try SomeFunc() else err {}

Desde mi publicación anterior en apoyo de la propuesta, he visto dos ideas publicadas por @jagv (sin parámetros try devuelve *error ) y por @josharian (controladores de errores etiquetados) que creo en un una forma ligeramente modificada mejoraría considerablemente la propuesta.

Juntando estas ideas con otra que he tenido yo mismo, tendríamos cuatro versiones de try :

1. tratar()
2. probar (parámetros)
3. probar (parámetros, etiqueta)
4. intentar (parámetros, pánico)

1 simplemente devolvería un puntero al parámetro de retorno de error (ERP) o nulo si no hubiera uno (#4 solamente). Esto proporcionaría una alternativa a un ERP con nombre sin la necesidad de agregar un integrado adicional.

2 funcionaría exactamente como se prevé actualmente. Se devolvería inmediatamente un error no nulo, pero se podría decorar con una instrucción defer .

3 funcionaría como lo sugiere @josharian , es decir, en un error no nulo, el código se ramificaría a la etiqueta. Sin embargo, no habría una etiqueta de controlador de errores predeterminada, ya que ese caso ahora degeneraría en el n. ° 2.

Me parece que esta suele ser una mejor manera de decorar los errores (o manejarlos localmente y luego devolverlos a cero) que defer , ya que es más simple y rápido. Cualquiera a quien no le haya gustado todavía podría usar el #2.

Sería una buena práctica colocar la etiqueta/código de manejo de errores cerca del final de la función y no volver al resto del cuerpo de la función. Sin embargo, no creo que el compilador deba hacer cumplir tampoco, ya que puede haber ocasiones extrañas en las que sean útiles y la aplicación puede ser difícil en cualquier caso.

Por lo tanto, la etiqueta normal y el comportamiento goto se aplicarían sujetos (como dijo @josharian ) a que #26058 se solucione primero, pero creo que debería solucionarse de todos modos.

El nombre de la etiqueta no puede ser panic ya que entraría en conflicto con el #4.

4 panic inmediatamente en lugar de regresar o ramificarse. En consecuencia, si esta fuera la única versión de try utilizada en una función particular, no se requeriría ningún ERP.

Agregué esto para que el paquete de prueba pueda funcionar como lo hace ahora sin la necesidad de más cambios integrados u otros. Sin embargo, también podría ser útil en otros escenarios _fatales_.

Esta debe ser una versión separada de try como la alternativa de bifurcarse a un controlador de errores y luego entrar en pánico aún requeriría un ERP.

Una de las reacciones más fuertes a la propuesta inicial fue la preocupación por perder la visibilidad del flujo normal de donde regresa una función.

Por ejemplo, @deanveloper expresó muy bien esa preocupación en https://github.com/golang/go/issues/32437#issuecomment -498932961, que creo que es el comentario más votado aquí.

@dominikh escribió en https://github.com/golang/go/issues/32437#issuecomment -499067357:

En código gofmt'ed, un retorno siempre coincide con /^\t*return / – es un patrón muy trivial para detectar a simple vista, sin ninguna ayuda. try, por otro lado, puede ocurrir en cualquier parte del código, anidado arbitrariamente en profundidad en las llamadas a funciones. Ninguna cantidad de capacitación nos permitirá detectar de inmediato todo el flujo de control en una función sin la ayuda de herramientas.

Para ayudar con eso, @brynbellomy sugirió ayer:

cualquier declaración de prueba (incluso aquellas sin un controlador) debe ocurrir en su propia línea.

Yendo más allá, se podría requerir que try sea el comienzo de la línea, incluso para una tarea.

Entonces podría ser:

try dm := DecodeMsg(m)
try um := dm.SaveToDB()
try EmitEvent(um)

en lugar de lo siguiente (del ejemplo de @brynbellomy ):

dm, err := DecodeMsg(m)
if err != nil {
    return nil, err
}

um, err := dm.SaveToDB()
if err != nil {
    return nil, err
}

err = EmitEvent(um)
if err != nil {
    return nil, err
}

Eso parece que preservaría una buena cantidad de visibilidad, incluso sin ningún editor o asistencia de IDE, al tiempo que reduce el modelo.

Eso podría funcionar con el enfoque basado en aplazamiento propuesto actualmente que se basa en parámetros de resultado con nombre, o podría funcionar especificando funciones de controlador normales. (Especificar funciones de controlador sin requerir valores de retorno con nombre me parece mejor que requerir valores de retorno con nombre, pero ese es un punto aparte).

La propuesta incluye este ejemplo:

info := try(try(os.Open(file)).Stat())    // proposed try built-in

Eso podría ser en cambio:

try f := os.Open(file)
try info := f.Stat()

Eso sigue siendo una reducción en el modelo estándar en comparación con lo que alguien podría escribir hoy, incluso si no es tan corto como la sintaxis propuesta. ¿Quizás eso sería lo suficientemente corto?

@elagergren-spideroak proporcionó este ejemplo:

try(try(try(to()).parse().this)).easily())

Creo que tiene paréntesis que no coinciden, lo que quizás sea un punto deliberado o un poco de humor sutil, por lo que no estoy seguro de si ese ejemplo pretende tener 2 try o 3 try . En cualquier caso, tal vez sería mejor exigir que se distribuya en 2 o 3 líneas que comiencen con try .

@thepudds , esto es a lo que me refería en mi comentario anterior. Excepto lo dado

try f := os.Open(file)
try info := f.Stat()

Una cosa obvia que hacer es pensar en try como un bloque de prueba donde se puede poner más de una oración entre paréntesis. Entonces lo anterior puede convertirse

try (
    f := os.Open(file)
    into := f.Stat()
)

Si el compilador sabe cómo lidiar con esto, lo mismo funciona para anidar también. Así que ahora lo anterior puede convertirse

try info := os.Open(file).Stat()

A partir de las firmas de funciones, el compilador sabe que Open puede devolver un valor de error y, como se encuentra en un bloque de prueba, necesita generar un manejo de errores y luego llamar a Stat() en el valor primario devuelto y así sucesivamente.

Lo siguiente es permitir declaraciones en las que no se genere ningún valor de error o se maneje localmente. Así que ahora puedes decir

try (
    f := os.Open(file)
    debug("f: %v\n", f) // debug returns nothing
    into := f.Stat()
)

Esto permite la evolución del código sin tener que reorganizar los bloques de prueba. ¡Pero por alguna extraña razón, la gente parece pensar que el manejo de errores debe explicarse explícitamente! Ellos quieren

try(try(try(to()).parse()).this)).easily())

Si bien estoy perfectamente bien con

try to().parse().this().easily()

Aunque en ambos casos se puede generar exactamente el mismo código de comprobación de errores. Mi opinión es que siempre puede escribir un código especial para el manejo de errores si es necesario. try (o como prefiera llamarlo) simplemente elimina el manejo de errores predeterminado (que consiste en enviarlo a la persona que llama).

Otro beneficio es que si el compilador genera el manejo de errores predeterminado, puede agregar más información de identificación para que sepa cuál de las cuatro funciones anteriores falló.

Estaba algo preocupado por la legibilidad de los programas donde aparece try dentro de otras expresiones. Así que ejecuté grep "return .*err$" en la biblioteca estándar y comencé a leer bloques al azar. Hay 7214 resultados, solo leí un par de cientos.

Lo primero a tener en cuenta es que donde se aplica try , hace que casi todos estos bloques sean un poco más legibles.

Lo segundo es que muy pocos de estos, menos de 1 de cada 10, pondrían try dentro de otra expresión. El caso típico son declaraciones de la forma x := try(...) o ^try(...)$ .

Aquí hay algunos ejemplos donde try aparecerían dentro de otra expresión:

texto/plantilla

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        lessOrEqual, err := le(arg1, arg2)
        if err != nil {
                return false, err
        }
        return !lessOrEqual, nil
}

se convierte en:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        return !try(le(arg1, arg2)), nil
}

texto/plantilla

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
...
        switch v.Kind() {
        case reflect.Map:
                index, err := prepareArg(index, v.Type().Key())
                if err != nil {
                        return reflect.Value{}, err
                }
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

se convierte

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
        ...
        switch v.Kind() {
        case reflect.Map:
                if x := v.MapIndex(try(prepareArg(index, v.Type().Key()))); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

(este es el ejemplo más cuestionable que vi)

expresión regular/sintaxis:

regexp/syntax/parse.go

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        if c, t, err = nextRune(t); err != nil {
                return nil, err
        }
        p.literal(c)
        ...
}

se convierte

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        c, t = try(nextRune(t))
        p.literal(c)
        ...
}

Este no es un ejemplo de probar dentro de otra expresión, pero quiero mencionarlo porque mejora la legibilidad. Es mucho más fácil ver aquí que los valores de c y t están más allá del alcance de la instrucción if.

red/http

net/http/request.go:readRequest

        mimeHeader, err := tp.ReadMIMEHeader()
        if err != nil {
                return nil, err
        }
        req.Header = Header(mimeHeader)

se convierte en:

        req.Header = Header(try(tp.ReadMIMEHeader())

base de datos/sql

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                connector, err := driverCtx.OpenConnector(dataSourceName)
                if err != nil {
                        return nil, err
                }
                return OpenDB(connector), nil
        }

se convierte

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                return OpenDB(try(driverCtx.OpenConnector(dataSourceName))), nil
        }

base de datos/sql

        si, err := ctxDriverPrepare(ctx, dc.ci, query)
        if err != nil {
                return nil, err
        }
        ds := &driverStmt{Locker: dc, si: si}

se convierte

        ds := &driverStmt{
                Locker: dc,
                si: try(ctxDriverPrepare(ctx, dc.ci, query)),
        }

red/http

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                cc, err := p.t.dialclientconn(addr, singleuse)
                if err != nil {
                        return nil, err
                }
                return cc, nil
        }

se convierte

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                return try(p.t.dialclientconn(addr, singleuse))
        }

red/http

func (f *http2Framer) endWrite() error {
        ...
        n, err := f.w.Write(f.wbuf)
        if err == nil && n != len(f.wbuf) {
                err = io.ErrShortWrite
        }
        return err
}

se convierte

func (f *http2Framer) endWrite() error {
        ...
        if try(f.w.Write(f.wbuf) != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

(Este me gusta mucho).

red/http

        if f, err := fr.ReadFrame(); err != nil {
                return nil, err
        } else {
                hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
        }

se convierte

        hc = try(fr.ReadFrame()).(*http2ContinuationFrame)// guaranteed by checkFrameOrder

}

(También agradable.)

neto :

        if ctrlFn != nil {
                c, err := newRawConn(fd)
                if err != nil {
                        return err
                }
                if err := ctrlFn(fd.ctrlNetwork(), laddr.String(), c); err != nil {
                        return err
                }
        }

se convierte

        if ctrlFn != nil {
                try(ctrlFn(fd.ctrlNetwork(), laddr.String(), try(newRawConn(fd))))
        }

tal vez esto es demasiado, y en su lugar debería ser:

        if ctrlFn != nil {
                c := try(newRawConn(fd))
                try(ctrlFn(fd.ctrlNetwork(), laddr.String(), c))
        }

En general, disfruto bastante el efecto de try en el código de la biblioteca estándar que leo.

Un punto final: Ver try aplicado para leer código más allá de los pocos ejemplos en la propuesta fue esclarecedor. Creo que vale la pena considerar escribir una herramienta para convertir automáticamente el código para usar try (donde no cambia la semántica del programa). Sería interesante leer una muestra de las diferencias que se producen con los paquetes populares en github para ver si se mantiene lo que encontré en la biblioteca estándar. El resultado de dicho programa podría proporcionar información adicional sobre el efecto de la propuesta.

@crawshaw gracias por hacer esto, fue genial verlo en acción. Pero verlo en acción me hizo tomar más en serio los argumentos en contra del manejo de errores en línea que hasta ahora había estado descartando.

Dado que esto estaba tan cerca de la interesante sugerencia de @thepudds de hacer try una declaración, reescribí todos los ejemplos usando esa sintaxis y lo encontré mucho más claro que la expresión- try o la status quo, sin requerir demasiadas líneas adicionales:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
        ...
        switch v.Kind() {
        case reflect.Map:
                try index := prepareArg(index, v.Type().Key())
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        try c, t = nextRune(t)
        p.literal(c)
        ...
}

        try mimeHeader := tp.ReadMIMEHeader()
        req.Header = Header(mimeHeader)

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                try connector := driverCtx.OpenConnector(dataSourceName)
                return OpenDB(connector), nil
        }

Podría decirse que este sería mejor con una expresión try si hubiera varios campos que tuvieran que ser try -ed, pero sigo prefiriendo el equilibrio de esta compensación

        try si := ctxDriverPrepare(ctx, dc.ci, query)
        ds := &driverStmt{Locker: dc, si: si}

Este es básicamente el peor de los casos para esto y se ve bien:

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                try cc := p.t.dialclientconn(addr, singleuse)
                return cc, nil
        }

Debatí conmigo mismo si if try sería o debería ser legal, pero no pude encontrar una explicación razonable de por qué no debería serlo y funciona bastante bien aquí:

func (f *http2Framer) endWrite() error {
        ...
        if try n := f.w.Write(f.wbuf); n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

        try f := fr.ReadFrame()
        hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder

        if ctrlFn != nil {
                try c := newRawConn(fd)
                try ctrlFn(fd.ctrlNetwork(), laddr.String(), c)
        }

Examinar los ejemplos de @crawshaw solo me hace sentir más seguro de que el flujo de control a menudo se volverá lo suficientemente críptico como para ser aún más cuidadoso con el diseño. Relacionar incluso una pequeña cantidad de complejidad se vuelve difícil de leer y fácil de estropear. Me alegra ver las opciones consideradas, pero complicar el flujo de control en un lenguaje tan cauteloso parece excepcionalmente fuera de lugar.

func (f *http2Framer) endWrite() error {
        ...
        if try(f.w.Write(f.wbuf) != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

Además, try no está "intentando" nada. Es un "relé de protección". Si la semántica base de la propuesta está desactivada, no me sorprende que el código resultante también sea problemático.

func (f *http2Framer) endWrite() error {
        ...
        relay n := f.w.Write(f.wbuf)
        return checkShortWrite(n, len(f.wbuf))
}

Si hace una declaración de prueba, podría usar una bandera para indicar qué valor de retorno y qué acción:

try c, @      := newRawConn(fd) // return
try c, <strong i="6">@panic</strong> := newRawConn(fd) // panic
try c, <strong i="7">@hname</strong> := newRawConn(fd) // invoke named handler
try c, <strong i="8">@_</strong>     := newRawConn(fd) // ignore, or invoke "ignored" handler if defined

Todavía necesita una sintaxis de subexpresión (Russ ha declarado que es un requisito), al menos para acciones de pánico e ignorar.

En primer lugar, aplaudo a @crawshaw por tomarse el tiempo de ver aproximadamente 200 ejemplos reales y por tomarse el tiempo para su reflexivo artículo anterior.

En segundo lugar, @jimmyfrasche , con respecto a su respuesta aquí sobre el ejemplo http2Framer :

Debatí conmigo mismo si if try sería o debería ser legal, pero no pude encontrar una explicación razonable de por qué no debería serlo y funciona bastante bien aquí:

```
func (f *http2Framer) endWrite() error {
...
si prueba n := fwWrite(f.wbuf); n != len(f.wbuf) {
volver io.ErrShortWrite
}
devolver cero
}

At least under what I was suggesting above in https://github.com/golang/go/issues/32437#issuecomment-500213884, under that proposal variation I would suggest `if try` is not allowed.

That `http2Framer` example could instead be:

func (f *http2Framer) endWrite() error {
...
prueba n := fwWrite(f.wbuf)
si n != len(f.wbuf) {
volver io.ErrShortWrite
}
devolver cero
}
`` That is one line longer, but hopefully still "light on the page". Personally, I think that (arguably) reads more cleanly, but more importantly it is easier to see the probar`.

@deanveloper escribió arriba en https://github.com/golang/go/issues/32437#issuecomment -498932961:

Regresar de una función parece haber sido algo "sagrado" de hacer

Ese ejemplo específico http2Framer termina no siendo tan corto como podría ser. Sin embargo, se mantiene regresando de una función más "sagrada" si el try debe ser lo primero en una línea.

@crawshaw mencionó:

Lo segundo es que muy pocos de estos, menos de 1 de cada 10, pondrían try dentro de otra expresión. El caso típico son las sentencias de la forma x := try(...) o ^try(...)$.

Tal vez esté bien ayudar solo parcialmente a esos 1 de cada 10 ejemplos con una forma más restringida de try , especialmente si el caso típico de esos ejemplos termina con el mismo número de líneas, incluso si try es requerido para ser lo primero en una línea?

@jimmyfrasche

@crawshaw gracias por hacer esto, fue genial verlo en acción. Pero verlo en acción me hizo tomar más en serio los argumentos en contra del manejo de errores en línea que hasta ahora había estado descartando.

Dado que esto estaba tan cerca de la interesante sugerencia de @thepudds de hacer try una declaración, reescribí todos los ejemplos usando esa sintaxis y lo encontré mucho más claro que la expresión- try o la status quo, sin requerir demasiadas líneas adicionales:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

Su primer ejemplo ilustra bien por qué prefiero la expresión- try . En su versión, tengo que poner el resultado de la llamada a le en una variable, pero esa variable no tiene un significado semántico que el término le no implica. Así que no hay ningún nombre que pueda darle que no tenga sentido (como x ) o redundante (como lessOrEqual ). Con expression- try , no se necesita una variable intermedia, por lo que este problema ni siquiera surge.

Prefiero no tener que gastar esfuerzo mental inventando nombres para cosas que es mejor dejar en el anonimato.

Estoy feliz de expresar mi apoyo detrás de las últimas publicaciones donde try (la palabra clave) se ha movido al principio de la línea. Realmente debería compartir el mismo espacio visual que return .

Re: la sugerencia de @jimmyfrasche de permitir try dentro de declaraciones compuestas if , ese es exactamente el tipo de cosas que creo que muchos aquí están tratando de evitar, por algunas razones:

• combina dos mecanismos de flujo de control muy diferentes en una sola línea
• la expresión try en realidad se evalúa primero y puede hacer que la función regrese, pero aparece después de if
• regresan con errores totalmente diferentes, uno de los cuales en realidad no vemos en el código y otro que hacemos
• hace que sea menos obvio que try en realidad no se maneja, porque el bloque se parece mucho a un bloque controlador (aunque está manejando un problema totalmente diferente)

Se podría abordar esta situación desde un ángulo ligeramente diferente que favorezca empujar a las personas a manejar try s. ¿Qué tal permitir que la sintaxis try / else contenga condicionales subsiguientes (que es un patrón común con muchas funciones de E/S que devuelven err y n , cualquiera de los cuales podría indicar un problema):

func (f *http2Framer) endWrite() error {
        // ...
        try n := f.w.Write(f.wbuf) else err {
                return errors.Wrap(err, "error writing:")
        } else if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

En el caso de que no maneje el error devuelto por .Write , aún tendría una anotación clara de que .Write podría tener un error (como lo señaló @thepudds):

func (f *http2Framer) endWrite() error {
        // ...
        try n := f.w.Write(f.wbuf)
        if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

Secundo la respuesta de @daved . En mi opinión, cada ejemplo que destacó @crawshaw se volvió menos claro y más propenso a errores como resultado de try .

Estoy feliz de expresar mi apoyo detrás de las últimas publicaciones donde try (la palabra clave) se ha movido al principio de la línea. Realmente debería compartir el mismo espacio visual que return .

Dadas las dos opciones para este punto y suponiendo que se eligió una y, por lo tanto, sentó un precedente para futuras características potenciales:

A.)

try f := os.Open(filepath) else err {
    return errors.Wrap(err, "can't open")
}

B.)

f := try os.Open(filepath) else err {
    return errors.Wrap(err, "can't open")
}

¿Cuál de los dos proporciona más flexibilidad para el uso futuro de nuevas palabras clave? _(No sé la respuesta a esto porque no domino el oscuro arte de escribir compiladores)._ ¿Sería un enfoque más limitante que otro?

@davecheney @daved @crawshaw
Tiendo a estar de acuerdo con los Dave en esto: en los ejemplos de @crawshaw , hay muchas declaraciones try incrustadas en lo profundo de las líneas que tienen muchas otras cosas en marcha. Puntos de salida realmente difíciles de detectar. Además, los try parecen desordenar bastante las cosas en algunos de los ejemplos.

Ver un montón de código stdlib transformado de esta manera es muy útil, así que tomé los mismos ejemplos pero los reescribí según la propuesta alternativa, que es más restrictiva:

• try como palabra clave
• solo un try por línea
• try debe estar al principio de una línea

Espero que esto nos ayude a comparar. Personalmente, encuentro que estos ejemplos parecen mucho más concisos que los originales, pero sin oscurecer el flujo de control. try permanece muy visible en cualquier lugar donde se use.

texto/plantilla

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        lessOrEqual, err := le(arg1, arg2)
        if err != nil {
                return false, err
        }
        return !lessOrEqual, nil
}

se convierte en:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

texto/plantilla

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
...
        switch v.Kind() {
        case reflect.Map:
                index, err := prepareArg(index, v.Type().Key())
                if err != nil {
                        return reflect.Value{}, err
                }
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

se convierte

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
        ...
        switch v.Kind() {
        case reflect.Map:
                try index := prepareArg(index, v.Type().Key())
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

expresión regular/sintaxis:

regexp/syntax/parse.go

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        if c, t, err = nextRune(t); err != nil {
                return nil, err
        }
        p.literal(c)
        ...
}

se convierte

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        try c, t = nextRune(t)
        p.literal(c)
        ...
}

red/http

net/http/request.go:readRequest

        mimeHeader, err := tp.ReadMIMEHeader()
        if err != nil {
                return nil, err
        }
        req.Header = Header(mimeHeader)

se convierte en:

        try mimeHeader := tp.ReadMIMEHeader()
        req.Header = Header(mimeHeader)

base de datos/sql

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                connector, err := driverCtx.OpenConnector(dataSourceName)
                if err != nil {
                        return nil, err
                }
                return OpenDB(connector), nil
        }

se convierte

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                try connector := driverCtx.OpenConnector(dataSourceName)
                return OpenDB(connector), nil
        }

base de datos/sql

        si, err := ctxDriverPrepare(ctx, dc.ci, query)
        if err != nil {
                return nil, err
        }
        ds := &driverStmt{Locker: dc, si: si}

se convierte

        try si := ctxDriverPrepare(ctx, dc.ci, query)
        ds := &driverStmt{Locker: dc, si: si}

red/http

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                cc, err := p.t.dialclientconn(addr, singleuse)
                if err != nil {
                        return nil, err
                }
                return cc, nil
        }

se convierte

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                try cc := p.t.dialclientconn(addr, singleuse)
                return cc, nil
        }

red/http
Este en realidad no nos ahorra ninguna línea, pero lo encuentro mucho más claro porque if err == nil es una construcción relativamente poco común.

func (f *http2Framer) endWrite() error {
        ...
        n, err := f.w.Write(f.wbuf)
        if err == nil && n != len(f.wbuf) {
                err = io.ErrShortWrite
        }
        return err
}

se convierte

func (f *http2Framer) endWrite() error {
        ...
        try n := f.w.Write(f.wbuf)
        if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

red/http

        if f, err := fr.ReadFrame(); err != nil {
                return nil, err
        } else {
                hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
        }

se convierte

        try f := fr.ReadFrame()
        hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
}

neto:

        if ctrlFn != nil {
                c, err := newRawConn(fd)
                if err != nil {
                        return err
                }
                if err := ctrlFn(fd.ctrlNetwork(), laddr.String(), c); err != nil {
                        return err
                }
        }

se convierte

        if ctrlFn != nil {
                try c := newRawConn(fd)
                try ctrlFn(fd.ctrlNetwork(), laddr.String(), c)
        }

@james-lawrence En respuesta a https://github.com/golang/go/issues/32437#issuecomment -500116099: No recuerdo que se hayan considerado seriamente ideas como un , err opcional, no. Personalmente, creo que es una mala idea, porque significa que si una función cambia para agregar un parámetro final error , el código existente continuará compilando, pero actuará de manera muy diferente.

El uso de defer para manejar los errores tiene mucho sentido, pero lleva a la necesidad de nombrar el error y un nuevo tipo de repetitivo if err != nil .

Los controladores externos deben hacer esto:

func handler(err *error) {
  if *err != nil {
    *err = handle(*err)
  }
} 

que se usa como

defer handler(&err)

Los controladores externos solo deben escribirse una vez, pero sería necesario que hubiera dos versiones de muchas funciones de manejo de errores: la que se pretende diferir y la que se usa de manera regular.

Los controladores internos deben hacer esto:

defer func() {
  if err != nil {
    err = handle(err)
  }
}()

En ambos casos, se debe nombrar el error de la función externa para poder acceder.

Como mencioné anteriormente en el hilo, esto se puede resumir en una sola función:

func catch(err *error, handle func(error) error) {
  if *err != nil && handle != nil {
    *err = handle(*err)
  }
}

Eso va en contra de la preocupación de @griesemer sobre la ambigüedad de las funciones del controlador nil y tiene su propio modelo defer y func(err error) error , además de tener que nombrar err en la función exterior.

Si try termina como una palabra clave, entonces podría tener sentido tener una palabra clave catch , que también se describe a continuación.

Sintácticamente, sería muy parecido a handle :

catch err {
  return handleThe(err)
}

Semánticamente, sería azúcar para el código del controlador interno anterior:

defer func() {
  if err != nil {
    err = handleThe(err)
  }
}()

Dado que es algo mágico, podría capturar el error de la función externa, incluso si no se nombró. (El err después catch es más como un nombre de parámetro para el bloque catch ).

catch tendría la misma restricción que try que debe estar en una función que devuelve un error final, ya que ambos son azúcar que depende de eso.

Eso no es tan poderoso como la propuesta original handle , pero obviaría el requisito de nombrar un error para poder manejarlo y eliminaría el nuevo texto estándar discutido anteriormente para los controladores internos mientras lo hace lo suficientemente fácil como para no requieren versiones separadas de funciones para controladores externos.

El manejo de errores complicado puede requerir no usar catch al igual que puede requerir no usar try .

Dado que ambos son azúcar, no es necesario usar catch con try . Los controladores catch se ejecutan cada vez que la función devuelve un error que no es nil , lo que permite, por ejemplo, realizar un registro rápido:

catch err {
  log.Print(err)
  return err
}

o simplemente envolviendo todos los errores devueltos:

catch err {
  return fmt.Errorf("foo: %w", err)
}

@ianlancetaylor

_"Creo que es una mala idea, porque significa que si una función cambia para agregar un parámetro final error , el código existente continuará compilando, pero actuará de manera muy diferente"._

Esa es probablemente la forma correcta de verlo, si puede controlar tanto el código ascendente como el descendente, de modo que si necesita cambiar la firma de una función para que también devuelva un error, entonces puede hacerlo.

Pero le pediría que considere lo que sucede cuando alguien no controla ni el flujo ascendente ni el flujo descendente de sus propios paquetes. Y también para considerar los casos de uso en los que se pueden agregar errores, y ¿qué sucede si es necesario agregar errores pero no puede forzar el cambio del código descendente?

¿Puede pensar en un ejemplo en el que alguien cambiaría la firma para agregar un valor de retorno? Para mí, por lo general, han caído en la categoría de _"No me di cuenta de que ocurriría un error"_ o _"Me siento perezoso y no quiero hacer el esfuerzo porque el error probablemente no sucederá". _

En ambos casos, podría agregar un retorno de error porque se hace evidente que es necesario manejar un error. Cuando eso sucede, si no puedo cambiar la firma porque no quiero romper la compatibilidad para otros desarrolladores que usan mis paquetes, ¿qué hacer? Supongo que la gran mayoría de las veces ocurrirá el error y que el código que llamó a la función que no devuelve el error actuará de manera muy diferente, _de todos modos._

En realidad, rara vez hago lo último, pero con demasiada frecuencia hago lo primero. Pero he notado que los paquetes de terceros con frecuencia ignoran los errores de captura donde deberían estar, y lo sé porque cuando abro su código en GoLand, las marcas en naranja brillante cada instancia. Me encantaría poder enviar solicitudes de extracción para agregar el manejo de errores a los paquetes que uso mucho, pero si lo hago, la mayoría no los aceptará porque estaría rompiendo sus firmas de código.

Al no ofrecer una forma compatible con versiones anteriores de agregar errores para que las funciones los devuelvan, los desarrolladores que distribuyen código y se preocupan por no romper cosas para sus usuarios no podrán evolucionar sus paquetes para incluir el manejo de errores como deberían.

¿Tal vez en lugar de considerar que el problema es que el código actuará de manera diferente, en lugar de ver el problema como un desafío de ingeniería con respecto a cómo minimizar la desventaja de un método que no captura activamente un error? Eso tendría un valor más amplio y a más largo plazo.

Por ejemplo, considere agregar un controlador de errores de paquete que se debe configurar antes de poder ignorar los errores.

Para ser sincero, el idioma de Go de devolver errores además de los valores de retorno regulares fue una de sus mejores innovaciones. Pero como sucede tan a menudo cuando mejora las cosas, a menudo expone otras debilidades y argumentaré que el manejo de errores de Go no innovó lo suficiente.

Nosotros, los Gophers, nos hemos empeñado en devolver un error en lugar de lanzar una excepción, por lo que la pregunta que tengo es _"¿Por qué no deberíamos estar devolviendo errores de cada función?"_ No siempre lo hacemos porque escribir código sin manejo de errores es más conveniente que codificar con él. Por lo tanto, omitimos el manejo de errores cuando creemos que podemos evitarlo. Pero con frecuencia adivinamos mal.

Entonces, si fuera posible descubrir cómo hacer que el código sea elegante y legible, diría que los valores devueltos y los errores realmente deberían manejarse por separado, y que _todas_ las funciones deberían tener la capacidad de devolver errores independientemente de sus firmas de funciones anteriores. Y lograr que el código existente maneje correctamente el código que ahora genera errores sería un esfuerzo que valdría la pena.

No he propuesto nada porque no he podido imaginar una sintaxis viable, pero si queremos ser honestos con nosotros mismos, ¿no ha sido todo en este hilo y relacionado con el manejo de errores de Go en general sobre el hecho de que el manejo de errores y la lógica del programa son extraños compañeros de cama, por lo que, idealmente, los errores se manejarían mejor fuera de banda de alguna manera.

try como palabra clave ciertamente ayuda con la legibilidad (frente a una llamada de función) y parece menos complejo. @brynbellomy @crawshaw gracias por tomarse el tiempo para escribir los ejemplos.

Supongo que mi pensamiento general es que try hace demasiado. Resuelve: llamar a la función, asignar variables, verificar el error y devolver el error si existe. Propongo que, en cambio, cortemos el alcance y resolvamos solo para el retorno condicional: "devolver si el último argumento no es nulo".

Probablemente no sea una idea nueva... Pero después de hojear las propuestas en la wiki de comentarios de error , no la encontré (no significa que no esté allí)

Mini propuesta de devolución condicionada

extracto:

err, thing := newThing(name)
refuse nil, err

También lo agregué a la wiki en "ideas alternativas"

No hacer nada también parece una opción muy razonable.

@alexhornbake eso me da una idea un poco diferente que sería más útil

assert(nil, err)
assert(len(a), len(b))
assert(true, condition)
assert(expected, given)

de esta manera, no solo se aplicaría a la verificación de errores, sino a muchos tipos de errores lógicos.

Lo dado se envolvería en un error y se devolvería.

@alexhornbake

Así como try en realidad no lo está intentando, refuse en realidad no se está "rechazando". La intención común aquí ha sido que estamos configurando un "relé de protección" ( relay es corto, preciso y aliterado a return ) que se "dispara" cuando uno de los valores cableados cumple una condición (es decir, es un error no nulo). Es una especie de disyuntor y, creo, puede agregar valor si su diseño se limitó a casos poco interesantes para simplemente reducir algunos de los repetitivos más bajos. Cualquier cosa remotamente compleja debe basarse en el código Go simple.

También felicito a cranshaw por su trabajo de revisión de la biblioteca estándar, pero llegué a una conclusión muy diferente... Creo que hace que casi todos esos fragmentos de código sean más difíciles de leer y más propensos a malentendidos.

        req.Header = Header(try(tp.ReadMIMEHeader())

Muy a menudo extrañaré que esto pueda fallar. Una lectura rápida me dice "bien, establezca el encabezado en Encabezado de ReadMimeHeader de la cosa".

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                return OpenDB(try(driverCtx.OpenConnector(dataSourceName))), nil
        }

Este, mis ojos simplemente se cruzan tratando de analizar esa línea OpenDB. Hay tanta densidad allí... Esto muestra el principal problema que tienen todas las llamadas a funciones anidadas, ya que tienes que leer de adentro hacia afuera, y tienes que analizarlo en tu cabeza para descubrir dónde está la parte más interna. .

También tenga en cuenta que esto puede regresar desde dos lugares diferentes en la misma línea... va a estar depurando, y va a decir que hubo un error devuelto desde esta línea, y lo primero que todos van a hacer es intentar descubra por qué OpenDB está fallando con este extraño error, cuando en realidad está fallando OpenConnector (o viceversa).

        ds := &driverStmt{
                Locker: dc,
                si: try(ctxDriverPrepare(ctx, dc.ci, query)),
        }   

Este es un lugar donde el código puede fallar donde antes sería imposible. Sin try , la construcción literal de la estructura no puede fallar . Mis ojos lo hojearán como "bien, construyendo un driverStmt... continuando..." y será tan fácil pasarlo por alto que, en realidad, esto puede causar un error en la función. La única forma en que eso hubiera sido posible antes es si ctxDriverPrepare entrara en pánico... y todos sabemos que ese es un caso que 1.) básicamente nunca debería suceder y 2.) si sucede, significa que algo anda drásticamente mal.

Probar una palabra clave y una declaración soluciona muchos de mis problemas con ella. Sé que no es compatible con versiones anteriores, pero no creo que usar una versión peor sea la solución al problema de la compatibilidad con versiones anteriores.

@daved No estoy seguro de seguir. ¿No te gusta el nombre o no te gusta la idea?

De todos modos, publiqué esto aquí como una alternativa... Si hay un interés legítimo, puedo abrir un nuevo tema para la discusión, no quiero contaminar este hilo (¿quizás demasiado tarde?) Los pulgares hacia arriba o hacia abajo en la idea original darán nosotros un sentido... Por supuesto abierto a nombres alternativos. La parte importante es el "retorno condicional sin tratar de manejar la asignación".

Aunque me gusta la propuesta de captura de @jimmyfrasche , me gustaría proponer una alternativa:
go handler fmt.HandleErrorf("copy %s %s", src, dst)
sería equivalente a:
go defer func(){ if(err != nil){ fmt.HandleErrorf(&err,"copy %s %s", src, dst) } }()
donde err es el último valor de retorno nombrado, con tipo error. Sin embargo, los controladores también se pueden usar cuando no se nombran los valores devueltos. El caso más general también estaría permitido:
go handler func(err *error){ *err = fmt.Errorf("foo: %w", *err) }() `
El principal problema que tengo con el uso de valores de retorno con nombre (que catch no resuelve) es que err es superfluo. Al diferir una llamada a un controlador como fmt.HandleErrorf , no hay un primer argumento razonable, excepto un puntero al valor de retorno del error, ¿por qué darle al usuario la opción de cometer un error?

En comparación con catch, la principal diferencia es que handler hace un poco más fácil llamar a los controladores predefinidos a expensas de hacer más detallado su definición en el lugar. No estoy seguro de que esto sea ideal, pero creo que está más en línea con la propuesta original.

@yiyus catch , como lo definí, no requiere que se nombre err en la función que contiene catch .

En catch err { , el err es el nombre del error dentro del bloque catch . Es como un nombre de parámetro de función.

Con eso, no hay necesidad de algo como fmt.HandleErrorf porque puedes usar el fmt.Errorf normal:

func f() error {
  catch err {
    return fmt.Errorf("foo: %w", err)
  }
  return errors.New("bar")
}

que devuelve un error que se imprime como foo: bar .

No me gusta este enfoque, debido a:

• La llamada a la función try() interrumpe la ejecución del código en la función principal.
• no hay palabra clave return , pero el código realmente regresa.

Se están proponiendo muchas formas de hacer controladores, pero creo que a menudo pasan por alto dos requisitos clave:

1. Tiene que ser significativamente diferente y mejor que if x, err := thingie(); err != nil { handle(err) } . Creo que las sugerencias del tipo try x := thingie else err { handle(err) } no alcanzan ese nivel. ¿Por qué no decir simplemente if ?

2. Debe ser ortogonal a la funcionalidad existente de defer . Es decir, debe ser lo suficientemente diferente como para que quede claro que el mecanismo de manejo propuesto es necesario por derecho propio sin crear casos extraños en las esquinas cuando interactúan el manejo y el aplazamiento.

Tenga en cuenta estos deseos mientras discutimos mecanismos alternativos para try /handle.

@carlmjohnson Me gusta la idea de catch de @jimmyfrasche con respecto a su punto 2: es solo azúcar de sintaxis para un defer que ahorra 2 líneas y le permite evitar tener que nombrar el valor de retorno del error (que en turn también requeriría que nombre todos los demás si aún no lo ha hecho). No plantea un problema de ortogonalidad con defer , porque es defer .

haciéndose eco de lo que dijo @ubombi :

La llamada a la función try() interrumpe la ejecución del código en la función principal.; no hay palabra clave de retorno, pero el código realmente regresa.

En Ruby, procs y lambdas son un ejemplo de lo que hace try ... Un proc es un bloque de código cuya declaración de retorno no devuelve el bloque en sí, sino la persona que llama.

Esto es exactamente lo que hace try ... es solo un proceso de Ruby predefinido.

Creo que si fuéramos a seguir esa ruta, tal vez podamos dejar que el usuario defina su propia función try introduciendo proc functions

Sigo prefiriendo if err != nil , porque es más legible, pero creo que try sería más beneficioso si el usuario definiera su propio proceso:

proc try(err *error, msg string) {
  if *err != nil {
    *err = fmt.Errorf("%v: %w", msg, *err)
    return
  }
}

Y luego puedes llamarlo:

func someFunc() (string, error) {
  err := doSomething()
  try(&err, "someFunc failed")
}

El beneficio aquí es que puede definir el manejo de errores en sus propios términos. Y también puede hacer un proc expuesto, privado o interno.

También es mejor que la cláusula handle {} en la propuesta original de Go2 porque puede definir esto solo una vez para todo el código base y no en cada función.

Una consideración para la legibilidad es que un func() y un proc() pueden llamarse de manera diferente, como func() y proc!() modo que un programador sepa que una llamada a proc en realidad podría regresar fuera del función de llamada.

@marwan-at-work, ¿no debería try(err, "someFunc failed") ser try(&err, "someFunc failed") en su ejemplo?

@dpinela gracias por la corrección, actualicé el código :)

La práctica común que estamos tratando de anular aquí es lo que sugiere el desenrollado estándar de la pila en muchos idiomas en una excepción (y por lo tanto, se seleccionó la palabra "intentar"...).
Pero si solo pudiéramos permitir una función (... probar () u otra) que retrocediera dos niveles en la traza, entonces

try := handler(err error) {     //which corelates with - try := func(err error) 
   if err !=nil{
       //do what ever you want to do when there's an error... log/print etc
       return2   //2 levels
   }
} 

y luego un código como
f := try(os.Open(nombre de archivo))
podría hacer exactamente lo que aconseja la propuesta, pero como es una función (o en realidad una "función de controlador"), el desarrollador tendrá mucho más control sobre lo que hace la función, cómo formatea el error en diferentes casos, use un controlador similar en todo el código para manejar (digamos) os.Open, en lugar de escribir fmt.Errorf("error al abrir el archivo %s ....") cada vez.
Esto también forzaría el manejo de errores como si "intentar" no estuviera definido; es un error de tiempo de compilación.

@guybrand Tener un retorno de dos niveles return2 (o "retorno no local" como se llama el concepto general en Smalltalk) sería un buen mecanismo de propósito general (también sugerido por @mikeschinkel en #32473) . Pero parece que todavía se necesita try en su sugerencia, por lo que no veo una razón para el return2 : el try solo puede hacer el return . Sería más interesante si también se pudiera escribir try localmente, pero eso no es posible para firmas arbitrarias.

@griesemer

_"así que no veo una razón para el return2 - el try solo puede hacer el return ."_

Una razón, como señalé en #32473 _(gracias por la referencia)_, sería permitir múltiples niveles de break y continue , además de return .

Gracias de nuevo a todos por todos los nuevos comentarios; es una inversión de tiempo significativa mantenerse al día con la discusión y escribir comentarios extensos. Y mejor aún, a pesar de los argumentos a veces apasionados, este ha sido un hilo bastante civilizado hasta ahora. ¡Gracias!

Aquí hay otro resumen rápido, esta vez un poco más condensado; disculpas a aquellos que no mencioné, olvidé o malinterpreté. En este punto, creo que están surgiendo algunos temas más importantes:

1) En general, se considera que usar una función integrada para la funcionalidad try es una mala elección: dado que afecta el flujo de control, debería ser _al menos_ una palabra clave ( @carloslenz "prefiere que sea una declaración sin paréntesis"); try como expresión no parece buena idea, perjudica la legibilidad ( @ChrisHines , @jimmyfrasche), son "devoluciones sin return ". @brynbellomy hizo un análisis real de try usados ​​como identificadores; parece haber muy pocos porcentajes, por lo que podría ser posible seguir la ruta de la palabra clave sin afectar demasiado el código.

2) @crawshaw se tomó un tiempo para analizar un par de cientos de casos de uso de la biblioteca estándar y llegó a la conclusión de que try como se proponía, casi siempre mejoraba la legibilidad. @jimmyfrasche llegó a la conclusión opuesta .

3) Otro tema es que usar defer para la decoración de errores no es lo ideal. @josharian señala que los defer siempre se ejecutan al regresar la función, pero si están aquí para la decoración de errores, solo nos preocupamos por su cuerpo si hay un error, lo que podría ser una fuente de confusión.

4) Muchos escribieron sugerencias para mejorar la propuesta. @zeebo , @patrick-nyt apoyan gofmt formato gofmt de declaraciones simples if en una sola línea (y estén contentos con el status quo). @jargv sugirió que try() (sin argumentos) podría devolver un puntero al error actualmente "pendiente", lo que eliminaría la necesidad de nombrar el resultado del error solo para que uno tenga acceso a él en un defer ; @masterada sugirió usar errorfunc() en su lugar. @velovix revivió la idea de un try de 2 argumentos donde el segundo argumento sería un controlador de errores.

@klaidliadon , @networkimprov están a favor de "operadores de asignación" especiales como f, # := os.Open() en lugar de try . @networkimprov presentó una propuesta alternativa más completa que investiga tales enfoques (consulte el número 32500). @mikeschinkel también presentó una propuesta alternativa que sugiere introducir dos nuevas funciones de lenguaje de propósito general que también podrían usarse para el manejo de errores, en lugar de try específicos de errores (consulte el problema n.º 32473). @josharian revivió una posibilidad que discutimos en GopherCon el año pasado donde try no regresa en caso de error sino que salta (con un goto ) a una etiqueta llamada error (alternativamente , try podría tomar el nombre de una etiqueta de destino).

5) Sobre el tema de try como palabra clave, han aparecido dos líneas de pensamiento. @brynbellomy sugirió una versión que alternativamente podría especificar un controlador:

a, b := try f()
a, b := try f() else err { /* handle error */ }

@thepudds va un paso más allá y sugiere try al principio de la línea, dando a try la misma visibilidad que return :

try a, b := f()

Ambos podrían funcionar con defer .

@griesemer

Gracias por la referencia a @mikeschinkel #32473, tiene mucho en común.

con respecto a

Pero parece que aún se necesita probar en su sugerencia
Aunque mi sugerencia se puede implementar con "cualquier" controlador y no con una "compilación/palabra clave/expresión" reservada, no creo que "intentar()" sea una mala idea (y, por lo tanto, no la voté), lo estoy intentando para "ampliarlo", por lo que mostraría más ventajas, muchos esperaban "una vez que se introduzca go 2.0"

Creo que esa también puede ser la fuente de las "vibraciones mixtas" que informó en su último resumen: no es "intentar () no mejora el manejo de errores", claro que sí, es "esperar a que Go 3.0 resuelva algún otro error importante manejo de dolores" personas mencionadas anteriormente, parece demasiado largo :)

Estoy realizando una encuesta sobre "problemas en el manejo de errores" (y algunas de las molestias son simplemente "no utilizo buenas prácticas", mientras que otras ni siquiera las imaginé que la gente (en su mayoría provenientes de otros idiomas) quisiera hacer - de cool a WTF).

Espero poder compartir algunos resultados interesantes pronto.

por último, ¡gracias por el increíble trabajo y la paciencia!

Mirando simplemente la longitud de la sintaxis propuesta actual en comparación con lo que está disponible ahora, el caso en el que el error solo debe devolverse sin manipularlo o decorarlo es el caso en el que se obtiene la mayor comodidad. Un ejemplo con mi sintaxis favorita hasta ahora:

try a, b := f() else err { return fmt.Errorf("Decorated: %s", err); }
if a,b, err :=f;  err != nil { return fmt.Errorf("Decorated: %s", err); }
try a, b := f()
if a,b, err :=f;  err != nil { return err; }

Entonces, a diferencia de lo que pensaba antes, tal vez sea simplemente suficiente para alterar go fmt, al menos para el caso de error decorado/manejado. Mientras que para pasar el caso de error, algo como intentar podría ser deseable como azúcar sintáctico para este caso de uso muy común.

Con respecto a try else , creo que las funciones de error condicional como fmt.HandleErrorf (editar: asumo que devuelve cero cuando la entrada es cero) en el comentario inicial funciona bien, por lo que agregar else es innecesario

a, b, err := doSomething()
try fmt.HandleErrorf(&err, "Decorated "...)

Como muchos otros aquí, prefiero que try sea una declaración en lugar de una expresión, principalmente porque una expresión que altera el flujo de control es completamente ajena a Go. También porque esto no es una expresión, debe estar al principio de la línea.

También estoy de acuerdo con @daved en que el nombre no es apropiado. Después de todo, lo que estamos tratando de lograr aquí es una asignación protegida, entonces, ¿por qué no usar guard como en Swift y hacer que la cláusula else sea opcional? Algo como

GuardStmt = "guard" ( Assignment | ShortVarDecl | Expression ) [  "else" Identifier Block ] .

donde Identifier es el nombre de la variable de error vinculado en el siguiente Block . Sin la cláusula else , simplemente regrese de la función actual (y use un controlador diferido para decorar los errores si es necesario).

Inicialmente no me gustó una cláusula else porque es solo azúcar sintáctica en torno a la asignación habitual seguida de if err != nil , pero después de ver algunos de los ejemplos, tiene sentido: usar guard aclara la intención.

EDITAR: algunos sugirieron usar cosas como catch para especificar de alguna manera diferentes controladores de errores. Encuentro else igualmente viable semánticamente hablando y ya está en el idioma.

Si bien me gusta la declaración try-else, ¿qué tal esta sintaxis?

a, b, (err) := func() else { return err }

La expresión try - else es un operador ternario.

a, b := try f() else err { ... }
fmt.Println(try g() else err { ... })`

Declaración try - else es una declaración if .

try a, b := f() else err { ... }
// (modulo scope of err) same as
a, b, err := f()
if err != nil { ... }

El try incorporado con un controlador opcional se puede lograr con una función de ayuda (a continuación) o sin usar try (no se muestra, todos sabemos cómo se ve).

a, b := try(f(), decorate)
// same as
a, b := try(g())
// where g is
func g() (whatever, error) {
  x, err := f()
  if err != nil {
    try(decorate(err))
  }
  return x, nil
}

Los tres reducen el modelo y ayudan a contener el alcance de los errores.

Ofrece los mayores ahorros para try incorporados, pero tiene los problemas mencionados en el documento de diseño.

Para la declaración try - else , proporciona una ventaja sobre el uso if en lugar de try . Pero la ventaja es tan marginal que me cuesta ver que se justifique, aunque me gusta.

Los tres asumen que es común necesitar un manejo especial de errores para errores individuales.

El manejo de todos los errores por igual se puede hacer en defer . Si se realiza el mismo manejo de errores en cada bloque else , eso es un poco repetitivo:

func printSum(a, b string) error {
  try x := strconv.Atoi(a) else err {
    return fmt.Errorf("printSum: %w", err)
  }
  try y := strconv.Atoi(b) else err {
    return fmt.Errorf("printSum: %w", err)
  }
  fmt.Println("result:", x + y)
  return nil
}

Ciertamente sé que hay momentos en que un cierto error requiere un manejo especial. Esos son los casos que sobresalen en mi memoria. Pero, si eso solo sucede, digamos, 1 de cada 100 veces, ¿no sería mejor mantener try simple y simplemente no usar try en esas situaciones? Por otro lado, si es más como 1 de cada 10 veces, agregar else /handler parece más razonable.

Sin embargo, sería interesante ver una distribución real de la frecuencia con la que try sin un controlador else frente a try con un controlador else Esos datos no son fáciles de recopilar.

Quiero ampliar el comentario reciente de @jimmyfrasche .

El objetivo de esta propuesta es reducir el modelo

    a, b, err := f()
    if err != nil {
        return nil, err
    }

Este código es fácil de leer. Solo vale la pena extender el lenguaje si podemos lograr una reducción considerable en el modelo. Cuando veo algo como

    try a, b := f() else err { return nil, err }

No puedo evitar sentir que no estamos ahorrando tanto. Estamos guardando tres líneas, lo cual es bueno, pero según mi cuenta, estamos recortando de 56 a 46 caracteres. Eso no es mucho. Comparar con

    a, b := try(f())

que pasa de 56 a 18 caracteres, una reducción mucho más significativa. Y aunque la instrucción try hace que el posible cambio de flujo de control sea más claro, en general no encuentro que la instrucción sea más legible. Aunque en el lado positivo, la instrucción try hace que sea más fácil anotar el error.

De todos modos, mi punto es: si vamos a cambiar algo, debería reducir significativamente el texto estándar o debería ser significativamente más legible. Este último es bastante difícil, por lo que cualquier cambio debe funcionar realmente en el primero. Si solo obtenemos una pequeña reducción en el modelo, en mi opinión, no vale la pena hacerlo.

Al igual que otros, me gustaría agradecer a @crawshaw por los ejemplos.

Al leer esos ejemplos, animo a las personas a intentar adoptar una mentalidad en la que no se preocupe por el flujo de control debido a la función try . Creo, quizás incorrectamente, que ese flujo de control se convertirá rápidamente en una segunda naturaleza para las personas que conocen el idioma. En el caso normal, creo que la gente simplemente dejará de preocuparse por lo que sucede en el caso de error. Intente leer esos ejemplos mientras mira try tal como ya lo hace con if err != nil { return err } .

Después de leer todo aquí, y después de una mayor reflexión, no estoy seguro de ver siquiera como una declaración algo que valga la pena agregar.

1. la justificación de esto parece ser la reducción de errores en el manejo del código de la placa de la caldera. En mi humilde opinión, "ordena" el código, pero en realidad no elimina la complejidad; simplemente lo oscurece . Esto no parece una razón lo suficientemente fuerte. La ida" sintaxis bellamente capturada al iniciar un hilo simultáneo. No tengo ese tipo de sensación de "¡ajá!" aquí. No se siente bien. La relación costo/beneficio no es lo suficientemente grande.

2. su nombre no refleja su función. En su forma más simple, lo que hace es esto: "si una función devuelve un error, la persona que llama regresa con un error" pero eso es demasiado largo :-) Como mínimo, se necesita un nombre diferente.

3. con el retorno implícito de try en caso de error, parece que Go está retrocediendo de mala gana al manejo de excepciones. Es decir, si A llama a estar en una guardia de prueba y B llama a C en una guardia de prueba, y C llama a D en una guardia de prueba, si D devuelve un error en efecto, ha causado un goto no local. Se siente demasiado "mágico".

4. y, sin embargo, creo que una mejor manera puede ser posible. Al elegir probar ahora, se cerrará esa opción.

@ianlancetaylor
Si entiendo correctamente la propuesta "intentar otra cosa", parece que el bloque else es opcional y está reservado para el manejo proporcionado por el usuario. En su ejemplo try a, b := f() else err { return nil, err } , la cláusula else es realmente redundante, y la expresión completa se puede escribir simplemente como try a, b := f()

Estoy de acuerdo con @ianlancetaylor ,
La legibilidad y el texto estándar son dos preocupaciones principales y quizás el impulso para
el manejo de errores de go 2.0 (aunque puedo agregar algunas otras preocupaciones importantes)

Asimismo, que la corriente

a, b, err := f()
if err != nil {
    return nil, err
}

Es muy legible.
Y como creo

if a, b, err := f(); err != nil {
    return nil, err
}

Es casi tan legible, pero tenía sus "problemas" de alcance, tal vez un

ifErr a, b, err := f() {
    return nil, err
}

Eso sería solo el ; err != parte nula, y no crearía un alcance, o

similar

intente a, b, err := f() {
devuelve cero, err
}

Conserva las dos líneas adicionales, pero sigue siendo legible.

El martes, 11 de junio de 2019, 20:19 Dmitriy Matrenichev, [email protected]
escribió:

@ianlancetaylor https://github.com/ianlancetaylor
Si entiendo correctamente la propuesta de "intentar otra cosa", parece que el bloque else
es opcional y está reservado para el manejo proporcionado por el usuario. en tu ejemplo
intente a, b := f() else err { return nil, err } la cláusula else es en realidad
redundante, y toda la expresión se puede escribir simplemente como try a, b :=
F()

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/golang/go/issues/32437?email_source=notifications&email_token=ABNEY4XPURMASWKZKOBPBVDPZ7NALA5CNFSM4HTGCZ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXN3VDA#issuecomment-50093944
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ABNEY4SAFK4M5NLABF3NZO3PZ7NALANCNFSM4HTGCZ7Q
.

@ianlancetaylor

De todos modos, mi punto es: si vamos a cambiar algo, debería reducir significativamente el texto estándar o debería ser significativamente más legible. Este último es bastante difícil, por lo que cualquier cambio debe funcionar realmente en el primero. Si solo obtenemos una pequeña reducción en el modelo, en mi opinión, no vale la pena hacerlo.

De acuerdo, y teniendo en cuenta que un else solo sería azúcar sintáctico (¡con una sintaxis extraña!), Muy probablemente se use solo en raras ocasiones, no me importa mucho. Sin embargo, todavía prefiero que try sea una declaración.

@ianlancetaylor Haciéndose eco de @DmitriyMV , el bloque else sería opcional. Permítanme presentar un ejemplo que ilustra ambos (y no parece demasiado equivocado en términos de la proporción relativa de bloques try manejados frente a no manejados en código real):

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {
    headRef, err := r.Head()
    if err != nil {
        return err
    }

    parentObjOne, err := headRef.Peel(git.ObjectCommit)
    if err != nil {
        return err
    }

    parentObjTwo, err := remoteBranch.Reference.Peel(git.ObjectCommit)
    if err != nil {
        return err
    }

    parentCommitOne, err := parentObjOne.AsCommit()
    if err != nil {
        return err
    }

    parentCommitTwo, err := parentObjTwo.AsCommit()
    if err != nil {
        return err
    }

    treeOid, err := index.WriteTree()
    if err != nil {
        return err
    }

    tree, err := r.LookupTree(treeOid)
    if err != nil {
        return err
    }

    remoteBranchName, err := remoteBranch.Name()
    if err != nil {
        return err
    }

    userName, userEmail, err := r.UserIdentityFromConfig()
    if err != nil {
        userName = ""
        userEmail = ""
    }

    var (
        now       = time.Now()
        author    = &git.Signature{Name: userName, Email: userEmail, When: now}
        committer = &git.Signature{Name: userName, Email: userEmail, When: now}
        message   = fmt.Sprintf(`Merge branch '%v' of %v`, remoteBranchName, remote.Url())
        parents   = []*git.Commit{
            parentCommitOne,
            parentCommitTwo,
        }
    )

    _, err = r.CreateCommit(headRef.Name(), author, committer, message, tree, parents...)
    if err != nil {
        return err
    }
    return nil
}

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {
    try headRef := r.Head()
    try parentObjOne := headRef.Peel(git.ObjectCommit)
    try parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    try parentCommitOne := parentObjOne.AsCommit()
    try parentCommitTwo := parentObjTwo.AsCommit()
    try treeOid := index.WriteTree()
    try tree := r.LookupTree(treeOid)
    try remoteBranchName := remoteBranch.Name()
    try userName, userEmail := r.UserIdentityFromConfig() else err {
        userName = ""
        userEmail = ""
    }

    var (
        now       = time.Now()
        author    = &git.Signature{Name: userName, Email: userEmail, When: now}
        committer = &git.Signature{Name: userName, Email: userEmail, When: now}
        message   = fmt.Sprintf(`Merge branch '%v' of %v`, remoteBranchName, remote.Url())
        parents   = []*git.Commit{
            parentCommitOne,
            parentCommitTwo,
        }
    )

    try r.CreateCommit(headRef.Name(), author, committer, message, tree, parents...)
    return nil
}

Si bien el patrón try / else no guarda muchos caracteres sobre el compuesto if , sí lo hace:

• unificar la sintaxis de manejo de errores con el try no manejado
• dejar en claro de un vistazo que un bloque condicional está manejando una condición de error
• danos la oportunidad de reducir las rarezas de alcance que sufren los compuestos if

Sin embargo, es probable que los try no manejados sean los más comunes.

@ianlancetaylor

Trate de leer esos ejemplos mientras observa, intente tal como ya lo hizo si err != nil { return err }.

No creo que eso sea posible/equivalente. Extrañar que existe un intento en una línea abarrotada, o qué envuelve exactamente, o que hay múltiples instancias en una línea... Esto no es lo mismo que marcar fácil/rápidamente un punto de retorno y no preocuparse por los detalles del mismo.

@ianlancetaylor

Cuando veo una señal de alto, la reconozco por su forma y color más que leyendo la palabra impresa en ella y reflexionando sobre sus implicaciones más profundas.

Mis ojos pueden ponerse vidriosos por if err != nil { return err } pero al mismo tiempo todavía lo registra, clara e instantáneamente.

Lo que me gusta de la variante de declaración try es que reduce el texto modelo pero de una manera que es fácil de disimular pero difícil de pasar por alto.

Puede significar una línea adicional aquí o allá, pero aún son menos líneas que el statu quo.

@brynbellomy

1. ¿Cómo ofrece manejar funciones que devuelven múltiples valores, como:
   func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) (hash, error) {
2. ¿Cómo mantendría el rastro de la línea correcta que devolvió el error?
3. descartando el problema del alcance (que puede resolverse de otras maneras), no estoy seguro

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {

    if headRef, err := r.Head(); err != nil {
        return err
    } else if parentObjOne, err := headRef.Peel(git.ObjectCommit); err != nil {
        return err
    } else parentObjTwo, err := remoteBranch.Reference.Peel(git.ObjectCommit); err != nil {
        return err
    } ...

no es tan diferente en cuanto a la legibilidad, sin embargo (o fmt.Errorf("error al obtener el encabezado: %s", err.Error() ) le permite modificar y proporcionar datos adicionales fácilmente.

Lo que sigue siendo un fastidio es el

1. tener que volver a comprobar; error! = cero
2. devolver el error tal como está si no queremos dar la información adicional, lo que en algunos casos no es una buena práctica, porque depende de la función que llame para reflejar un error "bueno" que insinuará "lo que salió mal ", en casos de funciones file.Open, close, Remove, Db, etc., muchas de las llamadas a funciones pueden devolver el mismo error (podemos discutir si eso significa que el desarrollador que escribió el error hizo un buen trabajo o no... pero SUCEDE) - y luego - tiene un error, probablemente lo registre desde la función que llamó
   " createMergeCommit ", pero no puedo rastrearlo hasta la línea exacta en la que ocurrió.

Lo siento si alguien ya publicó algo como esto (hay muchas buenas ideas: P) ¿Qué tal esta sintaxis alternativa?

fail := func(err error) error {
  log.Print("unexpected error", err)
  return err
}

a, b, err := f1()          // normal
c, d := f2() -> throw      // calls throw(err)
e, f := f3() -> panic      // calls panic(err)
g, h := f4() -> t.Error    // calls t.Error(err)
i, j := f5() -> fail       // calls fail(err)

es decir, tiene un -> handler a la derecha de una llamada de función que se llama si se devuelve err != nil. El controlador es cualquier función que acepta un error como único argumento y, opcionalmente, devuelve un error (es decir, func(error) o func(error) error ). Si el controlador devuelve un error nulo, la función continúa; de lo contrario, se devuelve el error.

entonces a := b() -> handler es equivalente a:

a, err := b()
if err != nil {
  if herr := handler(err); herr != nil {
    return herr
  }
}

Ahora, como atajo, podría admitir un try incorporado (o una palabra clave o un operador ?= o lo que sea) que es la abreviatura de a := b() -> throw por lo que podría escribir algo como:

func() error {
  a, b := try(f1())
  c, d := try(f2())
  e, f := try(f3())
  ...
  return nil
}() -> panic // or throw/fail/whatever

Personalmente, encuentro que un operador ?= es más fácil de leer que una palabra clave/integrada de prueba:

func() error {
  a, b ?= f1()
  c, d ?= f2()
  e, f ?= f3()
  ...
  return nil
}() -> panic

nota : aquí estoy usando throw como marcador de posición para un elemento integrado que devolvería el error a la persona que llama.

No he comentado sobre las propuestas de manejo de errores hasta ahora porque generalmente estoy a favor y me gusta la forma en que se dirigen. Tanto la función de prueba definida en la propuesta como la declaración de prueba propuesta por @thepudds parecen ser adiciones razonables al lenguaje. Confío en que lo que se le ocurra al equipo de Go será bueno.

Quiero mencionar lo que veo como un problema menor con la forma en que se define try en la propuesta y cómo podría afectar futuras extensiones.

Try se define como una función que toma un número variable de argumentos.

func try(t1 T1, t2 T2, … tn Tn, te error) (T1, T2, … Tn)

Pasar el resultado de una llamada de función a try como en try(f()) funciona implícitamente debido a la forma en que funcionan los valores de retorno múltiples en Go.

Según mi lectura de la propuesta, los siguientes fragmentos son válidos y semánticamente equivalentes.

a, b = try(f())
//
u, v, err := f()
a, b = try(u, v, err)

La propuesta también plantea la posibilidad de ampliar try con argumentos extra.

Si determinamos en el camino que es una buena idea tener algún tipo de función de manejo de errores proporcionada explícitamente, o cualquier otro parámetro adicional, es trivialmente posible pasar ese argumento adicional a una llamada de prueba.

Supongamos que queremos agregar un argumento de controlador. Puede ir al principio o al final de la lista de argumentos.

var h handler
a, b = try(h, f())
// or
a, b = try(f(), h)

Ponerlo al principio no funciona porque (dada la semántica anterior) try no podría distinguir entre un argumento de controlador explícito y una función que devuelve un controlador.

func f() (handler, error) { ... }
func g() (error) { ... }
try(f())
try(h, g())

Ponerlo al final probablemente funcionaría, pero luego intentar sería único en el lenguaje como la única función con un parámetro varargs al principio de la lista de argumentos.

Ninguno de estos problemas es sensacional, pero hacen que try se sienta inconsistente con el resto del lenguaje, por lo que no estoy seguro de que try sea fácil de extender en el futuro como el establece la propuesta.

@mágico

Tener un controlador es poderoso, tal vez:
Yo ya declaraste h,

puede

var h handler
a, b, h = f()

o

a, b, h.err = f()

si es una función como:

h:= handler(err error){
 log(...)
 return ....
} 

Entonces hubo una sugerencia para

a, b, h(err) = f()

Todos pueden invocar al controlador.
Y también puede "seleccionar" el controlador que devuelve o solo captura el error (continuar/romper/regresar) como algunos sugirieron.

Y así se acabó el problema de los varargs.

Una alternativa a la sugerencia de else de @brynbellomy de:

a, b := try f() else err { /* handle error */ }

podría ser para apoyar una función de decoración inmediatamente después del else:

decorate := func(err error) error { return fmt.Errorf("foo failed: %v", err) }

try a, b := f() else decorate
try c, d := g() else decorate

Y tal vez también algunas funciones de utilidad algo como:

decorate := fmt.DecorateErrorf("foo failed")

La función de decoración podría tener la firma func(error) error y ser llamada por try en presencia de un error, justo antes de que try regrese de la función asociada que se está probando.

Eso sería similar en espíritu a una de las "iteraciones de diseño" anteriores del documento de propuesta:

f := try(os.Open(filename), handler)              // handler will be called in error case

Si alguien quiere algo más complejo o un bloque de declaraciones, podría usar if (tal como lo hace hoy).

Dicho esto, hay algo bueno en la alineación visual de try que se muestra en el ejemplo de @brynbellomy en https://github.com/golang/go/issues/32437#issuecomment -500949780.

Todo esto aún podría funcionar con defer si se elige ese enfoque para la decoración de errores uniforme (o incluso en teoría podría haber una forma alternativa de registrar una función de decoración, pero ese es un punto aparte).

En cualquier caso, no estoy seguro de qué es lo mejor aquí, pero quería hacer explícita otra opción.

Aquí está el ejemplo de @brynbellomy reescrito con la función try , usando un bloque var para conservar la buena alineación que @thepudds señaló en https://github.com/golang/go/issues /32437#issuecomentario -500998690.

package main

import (
    "fmt"
    "time"
)

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {
    var (
        headRef          = try(r.Head())
        parentObjOne     = try(headRef.Peel(git.ObjectCommit))
        parentObjTwo     = try(remoteBranch.Reference.Peel(git.ObjectCommit))
        parentCommitOne  = try(parentObjOne.AsCommit())
        parentCommitTwo  = try(parentObjTwo.AsCommit())
        treeOid          = try(index.WriteTree())
        tree             = try(r.LookupTree(treeOid))
        remoteBranchName = try(remoteBranch.Name())
    )

    userName, userEmail, err := r.UserIdentityFromConfig()
    if err != nil {
        userName = ""
        userEmail = ""
    }

    var (
        now       = time.Now()
        author    = &git.Signature{Name: userName, Email: userEmail, When: now}
        committer = &git.Signature{Name: userName, Email: userEmail, When: now}
        message   = fmt.Sprintf(`Merge branch '%v' of %v`, remoteBranchName, remote.Url())
        parents   = []*git.Commit{
            parentCommitOne,
            parentCommitTwo,
        }
    )

    _, err = r.CreateCommit(headRef.Name(), author, committer, message, tree, parents...)
    return err
}

Es tan sucinto como la versión de declaración try , y diría que es igual de legible. Dado que try es una expresión, algunas de esas variables intermedias podrían eliminarse, a costa de cierta legibilidad, pero eso parece más una cuestión de estilo que cualquier otra cosa.

Sin embargo, plantea la cuestión de cómo funciona try en un bloque var . Supongo que cada línea de var cuenta como una declaración separada, en lugar de que todo el bloque sea una sola declaración, en cuanto al orden de lo que se asigna y cuándo.

Sería bueno que la propuesta de "probar" mencionara explícitamente las consecuencias de herramientas como cmd/cover que aproximan las estadísticas de cobertura de prueba mediante el conteo de declaraciones ingenuas. Me preocupa que el flujo de control de errores invisible pueda resultar en un conteo insuficiente.

@thepudds

prueba a, b := f() sino decora

Tal vez es una quemadura demasiado profunda en mis células cerebrales, pero esto me golpea demasiado como una

try a, b := f() ;catch(decorate)

y una pendiente resbaladiza a un

a, b := f()
catch(decorate)

Creo que puedes ver a dónde lleva eso, y para mí comparar

    try headRef := r.Head()
    try parentObjOne := headRef.Peel(git.ObjectCommit)
    try parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    try parentCommitOne := parentObjOne.AsCommit()
    try parentCommitTwo := parentObjTwo.AsCommit()
    try treeOid := index.WriteTree()
    try tree := r.LookupTree(treeOid)
    try remoteBranchName := remoteBranch.Name()

con

    try ( 
    headRef := r.Head()
    parentObjOne := headRef.Peel(git.ObjectCommit)
    parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    parentCommitOne := parentObjOne.AsCommit()
    parentCommitTwo := parentObjTwo.AsCommit()
    treeOid := index.WriteTree()
    tree := r.LookupTree(treeOid)
    remoteBranchName := remoteBranch.Name()
    )

(o incluso una captura al final)
El segundo es más legible, pero enfatiza el hecho de que las funciones a continuación devuelven 2 vars, y mágicamente descartamos uno, recopilándolo en un "error mágico devuelto".

    try(err) ( 
    headRef := r.Head()
    parentObjOne := headRef.Peel(git.ObjectCommit)
    parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    parentCommitOne := parentObjOne.AsCommit()
    parentCommitTwo := parentObjTwo.AsCommit()
    treeOid := index.WriteTree()
    tree := r.LookupTree(treeOid)
    remoteBranchName := remoteBranch.Name()
    ); err!=nil {
      //handle the err
    }

al menos configura explícitamente la variable para que regrese, y déjame manejarla dentro de la función, cuando quiera.

Solo intercalando un comentario específico ya que no vi a nadie más mencionarlo explícitamente, específicamente sobre cambiar gofmt para admitir el siguiente formato de una sola línea, o cualquier variante:

if f() { return nil, err }

Por favor no. Si queremos una sola línea if , haga una sola línea if , por ejemplo:

if f() then return nil, err

Pero por favor, por favor, no adopte la ensalada de sintaxis eliminando los saltos de línea que facilitan la lectura del código que usa llaves.

Me gusta enfatizar un par de cosas que pueden haberse olvidado en el fragor de la discusión:

1) El punto central de esta propuesta es hacer que el manejo de errores comunes se desvanezca en segundo plano: el manejo de errores no debe dominar el código. Pero aún debe ser explícito. Cualquiera de las sugerencias alternativas que hacen que el manejo de errores se destaque aún más no tiene sentido. Como @ianlancetaylor ya dijo, si estas sugerencias alternativas no reducen significativamente la cantidad de repetitivo, podemos quedarnos con las declaraciones if . (Y la solicitud de reducir el modelo estándar proviene de usted, la comunidad de Go).

2) Una de las quejas sobre la propuesta actual es la necesidad de nombrar el resultado del error para poder acceder a él. Cualquier propuesta alternativa tendrá el mismo problema a menos que la alternativa introduzca una sintaxis adicional, es decir, más repetitivo (como ... else err { ... } y similares) para nombrar explícitamente esa variable. Pero lo que es interesante: si no nos importa decorar un error y no nombramos los parámetros de resultado, pero aún así requerimos un return explícito porque hay una especie de controlador explícito, esa instrucción return tendrá que enumerar todos los valores de resultado (normalmente cero) ya que en este caso no se permite una devolución simple. Especialmente si una función devuelve muchos errores sin decorar el error, esos retornos explícitos ( return nil, err , etc.) se suman al modelo. La propuesta actual y cualquier alternativa que no requiera un return explícito elimina eso. Por otro lado, si uno quiere decorar el error, la propuesta actual _requiere_ que uno nombre el resultado del error (y con eso todos los demás resultados) para tener acceso al valor del error. Esto tiene el agradable efecto secundario de que en un controlador explícito se puede usar un retorno simple y no es necesario repetir todos los demás valores de resultado. (Sé que hay algunos sentimientos fuertes acerca de las devoluciones desnudas, pero la realidad es que cuando todo lo que nos importa es el resultado del error, es una verdadera molestia tener que enumerar todos los demás valores de resultado (normalmente cero); no agrega nada a la comprensión del código). En otras palabras, tener que nombrar el resultado del error para que se pueda decorar permite una mayor reducción del modelo.

@magical Gracias por señalar esto . Me di cuenta de lo mismo poco después de publicar la propuesta (pero no la mencioné para no causar más confusión). Tiene razón en que tal como está, try no se pudo extender. Afortunadamente, la solución es bastante fácil. (Sucede que nuestras propuestas internas anteriores no tenían este problema; se introdujo cuando reescribí nuestra versión final para su publicación e intenté simplificar try para que coincidiera más con las reglas de paso de parámetros existentes. Parecía una buena - pero resulta que es defectuoso y en su mayoría inútil - beneficio de poder escribir try(a, b, c, handle) .)

Una versión anterior de try lo definía más o menos de la siguiente manera: try(expr, handler) toma una (o quizás dos) expresiones como argumentos, donde la primera expresión puede tener varios valores (solo puede ocurrir si la expresión es una llamada de función). El último valor de esa expresión (posiblemente de varios valores) debe ser del tipo error , y ese valor se compara con cero. (etc. - el resto te lo puedes imaginar).

De todos modos, el punto es que try sintácticamente acepta solo una, o quizás dos expresiones. (Pero es un poco más difícil describir la semántica de try ). La consecuencia sería ese código como:

a, b := try(u, v, err)

ya no estaría permitido. Pero hay pocas razones para hacer que esto funcione en primer lugar: en la mayoría de los casos (a menos que a y b sean resultados nombrados) este código, si es importante por alguna razón, podría reescribirse fácilmente en

a, b := u, v  // we don't care if the assignment happens in case of an error
try(err)

(o use una instrucción if según sea necesario). Pero, de nuevo, esto parece poco importante.

esa declaración de devolución tendrá que enumerar todos los valores de resultado (normalmente cero) ya que no se permite una devolución simple en este caso

No se permite una devolución desnuda, pero intentarlo sí. Una cosa que me gusta de try (ya sea como una función o una declaración) es que ya no tendré que pensar cómo establecer valores que no sean de error cuando devuelva un error, solo usaré try.

@griesemer Gracias por la explicación. Esa es la conclusión a la que también llegué.

Un breve comentario sobre try como declaración: como creo que se puede ver en el ejemplo en https://github.com/golang/go/issues/32437#issuecomment -501035322, el try entierra el lede. El código se convierte en una serie de declaraciones try , lo que oscurece lo que realmente está haciendo el código.

El código existente puede reutilizar una variable de error recién declarada después del bloque if err != nil . Ocultar la variable rompería eso, y agregar una variable de retorno con nombre a la firma de la función no siempre lo solucionará.

Tal vez sea mejor dejar la declaración/asignación de error como está y encontrar una instrucción de manejo de errores de una línea.

err := f() // followed by one of

on err, return err            // any type can be tested for non-zero
on err, return fmt.Errorf(...)
on err, fmt.Println(err)      // doesn't stop the function
on err, hname err             // handler invocation without parens
on err, ignore err            // optional ignore handler logs error if defined

if err, return err            // alternatively, use if

handle hname(err error, clr caller) { // type caller has results of runtime.Caller()
   if err == io.Bad { return err }
   fmt.Println(clr.name, err)
}

Una subexpresión try podría entrar en pánico, lo que significa que nunca se espera un error. Una variante de eso podría ignorar cualquier error.

f(try g()) // panic on error
f(try_ g()) // ignore any error

El objetivo de esta propuesta es hacer que el manejo de errores comunes pase a un segundo plano: el manejo de errores no debe dominar el código. Pero aún debe ser explícito.

Me gusta la idea de que los comentarios incluyan try como declaración. Es explícito, todavía fácil de pasar por alto (ya que tiene una longitud fija), pero no tan fácil de pasar por alto (ya que siempre está en el mismo lugar) que se pueden ocultar en una línea llena de gente. También se puede combinar con el defer fmt.HandleErrorf(...) como se indicó anteriormente, sin embargo, tiene la trampa de abusar de los parámetros con nombre para envolver errores (lo que todavía me parece un truco inteligente. Los trucos inteligentes son malos).

Una de las razones por las que no me gustó try como expresión es que es demasiado fácil de pasar por alto o no lo suficientemente fácil de pasar por alto. Tome los siguientes dos ejemplos:

Prueba como una expresión

// Too hidden, it's in a crowded function with many symbols that complicate the function.

f, err := os.OpenFile(try(FileName()), os.O_APPEND|os.O_WRONLY, 0600)

// Not easy enough, the word "try" already increases horizontal complexity, and it
// being an expression only encourages more horizontal complexity.
// If this code weren't collapsed to multiple lines, it would be extremely
// hard to read and unclear as to what's executing when.

fullContents := try(io.CopyN(
    os.Stdout,
    try(net.Dial("tcp", "localhost:"+try(buf.ReadString("\n"))),
    try(strconv.Atoi(try(buf.ReadString("\n")))),
))

Prueba como declaración

// easy to see while still not being too verbose

try name := FileName()
os.OpenFile(name, os.O_APPEND|os.O_WRONLY, 0600)

// does not allow for clever one-liners, code remains much more readable.
// also, the code reads in sequence from top-to-bottom.

try port := r.ReadString("\n")
try lengthStr := r.ReadString("\n")
try length := strconv.Atoi(lengthStr)

try con := net.Dial("tcp", "localhost:"+port)
try io.CopyN(os.Stdout, con, length)

comida para llevar

Este código es definitivamente artificial, lo admito. Pero lo que quiero decir es que, en general, try como expresión no funciona bien en:

1. El medio de expresiones abarrotadas que no necesitan mucha verificación de errores
2. Declaraciones de varias líneas relativamente simples que requieren una gran cantidad de verificación de errores

Sin embargo, estoy de acuerdo con @ianlancetaylor en que comenzar cada línea con try parece interferir con la parte importante de cada declaración (la variable que se define o la función que se ejecuta). Sin embargo, creo que debido a que está en la misma ubicación y tiene un ancho fijo, es mucho más fácil pasarlo por alto, sin dejar de notarlo. Sin embargo, los ojos de todos son diferentes.

También creo que fomentar frases ingeniosas en el código es una mala idea en general. Me sorprende que pudiera crear una línea tan poderosa como en mi primer ejemplo, es un fragmento que merece su función completa porque está haciendo mucho, pero cabe en una línea si no lo hubiera colapsado. a múltiples por el bien de la legibilidad. Todo en una línea:

fullContents := try(io.CopyN(os.Stdout, try(net.Dial("tcp", "localhost:"+try(r.ReadString("\n"))), try(strconv.Atoi(try(r.ReadString("\n"))))))

Lee un puerto desde un *bufio.Reader , inicia una conexión TCP y copia una cantidad de bytes especificados por el mismo *bufio.Reader a stdout . Todo con manejo de errores. Para un lenguaje con convenciones de codificación tan estrictas, no creo que esto deba permitirse. Sin embargo, supongo que gofmt podría ayudar con esto.

Para un lenguaje con convenciones de codificación tan estrictas, no creo que esto deba permitirse.

Es posible escribir código abominable en Go. Incluso es posible formatearlo terriblemente; solo hay normas y herramientas fuertes en su contra. Ir incluso tiene goto .

Durante las revisiones de código, a veces pido a las personas que dividan expresiones complicadas en varias declaraciones, con nombres intermedios útiles. Yo haría algo similar para try s profundamente anidados, por la misma razón.

Lo cual es todo para decir: no intentemos demasiado prohibir el código incorrecto, a costa de distorsionar el lenguaje. Tenemos otros mecanismos para mantener limpio el código que son más adecuados para algo que involucra fundamentalmente el juicio humano caso por caso.

Es posible escribir código abominable en Go. Incluso es posible formatearlo terriblemente; solo hay normas y herramientas fuertes en su contra. Ir incluso tiene goto.

Durante las revisiones de código, a veces pido a las personas que dividan expresiones complicadas en varias declaraciones, con nombres intermedios útiles. Yo haría algo similar para intentos profundamente anidados, por la misma razón.

Lo cual es todo para decir: no intentemos demasiado prohibir el código incorrecto, a costa de distorsionar el lenguaje. Tenemos otros mecanismos para mantener limpio el código que son más adecuados para algo que involucra fundamentalmente el juicio humano caso por caso.