Después de muchos años de experiencia trabajando con php y js, estoy acostumbrado a tener un seguimiento de la pila en los errores y mirar el lugar donde ocurrió el error directamente del informe de errores. Reposicionando en Go hace un par de años, me sorprendió un poco que Go tenga reglas diferentes y que necesite adivinar el rastro de la pila en alguna línea como `carácter inválido`. Y si sucedió en el producto y no se sabe cómo reproducirlo, entonces esto se convirtió en una atracción completa.
Como estoy seguro de que nadie sufrió esto, hice un paquete que puede hacer esto:

→
GitHubTodo lo que hace es:
- Agrega seguimiento de pila a errores.
- Muestra el seguimiento de la pila y los fragmentos de origen donde se produjo este error (en presencia de origen, por supuesto).
Agregar seguimiento de pila
Hay varias formas de crear un error con un seguimiento de pila:
Cuando el error se vuelve a envolver, el seguimiento de la pila seguirá siendo el mismo y no se sobrescribirá, esto es conveniente si no se sabe si el error ya tiene un seguimiento de la pila o no.
El código puede verse así:
func decodeFile(path string, data interface{}) error { b, err := ioutil.ReadFile(path) if err != nil { return tracerr.Wrap(err) } err = json.Unmarshal(b, data)
Pantalla de seguimiento de pila
Después del error a través de 100500
if err != nil { return err }
regresa a su Homeland en
main()
(o donde se procesa), lo más probable es que desee mostrarlo o comprometerlo.
Hay varias opciones para esto: todos funcionan como Imprimir (imprime texto) o Sprint (devuelve texto):
1) Mostrar texto de error y seguimiento de pila:
tracerr.Print(err)
2) Muestra el texto de error, el seguimiento de la pila y el fragmento de origen (6 líneas por defecto):
tracerr.PrintSource(err)
3) Lo mismo, pero en color, generalmente más informativo:
tracerr.PrintSourceColor(err)
4) Puede pasar como parámetro cuántas líneas de código mostrar:
tracerr.PrintSource(err, 9) tracerr.PrintSourceColor(err, 9)
5) O pase 2 parámetros opcionales, cuántos antes y cuánto después de la línea con el error para mostrar:
tracerr.PrintSource(err, 5, 2) tracerr.PrintSourceColor(err, 5, 2)
Preguntas
Ya he recibido algunos comentarios, por lo que me permito responder por adelantado algunas de las preguntas que ya se han formulado.
P: ¿Esto es adecuado solo para la depuración? Hay un depurador.R: Esto es adecuado no solo para la depuración, es posible registrar errores con información sobre el seguimiento de la pila, e incluso con fragmentos de códigos fuente, en el producto, como en mi experiencia, esto simplificará enormemente y luego analizará estos errores.
P: Hay un paquete súper paquete / errores, ¿por qué no usarlo?R: Sí, yo mismo lo usé por completo y me alegro, pero no me convenía por estos motivos:
1) No hay una manera fácil de mostrar un seguimiento de la pila inmediatamente con la fuente.
2) Cuando el error se vuelve a envolver (por ejemplo, un nivel más alto), el seguimiento de la pila se sobrescribe con otros menos informativos.
3) Es imperativo enviar un mensaje de error adicional con cada turno, lo que me parece una sobrecarga al escribir / leer código.
P: En Go, los errores no son excepciones y no puede hacer esto en absoluto.R: Estoy de acuerdo, los errores en Go no son una excepción. Si prefiere procesar miles
if err != nil { return err }
alguna otra manera, esta es su elección, por supuesto. Solo puede ajustar los errores que maneja como excepciones.
P: Stectrace agrega una sobrecarga al rendimiento.R: Sí, agrega, pero esto es relevante solo para lugares donde se crean errores en grandes cantidades, simplemente no agregue un seguimiento de pila allí si es crítico (estoy seguro de que en la mayoría de los casos esta sobrecarga es insignificante).
En general, espero que este paquete haga su vida más fácil, me alegrará recibir sus comentarios, gracias.