You are logging the same error many times and then trying to solve that in the logs.
Try this: Only log the error where it is handled, otherwise wrap it and return it without logging. At some point, you will log it as either an error if there is nothing you can do about it, or a warning if somehow you can recover from it (not panic recover). However your log record will contain the trace from the point where the error occurred, so you have all the information you need. In short: log the error once, at the point you handle it. On Thu, Aug 10, 2023 at 8:38 PM jal...@gmail.com <jalo...@gmail.com> wrote: > Hi all, > > I've adopted slog and I am really loving the library. As I have used this > on my team, I've noticed a repetitive problem with error wrapping and I am > curious how other folks have handled this problem. > > Lets say you are calling a sequence of functions where one function > depends on the result of the next function in the sequence. Each function > returns an error. For traceability, you want to log the error where it was > encountered, then wrap the error in the current function and return it. You > then repeat this all the way up the stack. See here for a simplified > example: > > https://go.dev/play/p/uDWU1JucG5W > > This has the benefit of clearly communicating what caused the failure in > each function. It has the drawback that you are repeatedly logging the same > error information multiple times. Depending on the error text, this could > turn into a wall of text that makes interpreting logs quite hard for an > engineer. I learned this the hard way when i use github.com/pkg/errors > and would print out the stacktrace. > > So then I wondered about using context to inject a traceId that would link > log messages together. I banged out quickly a small library as a PoC. > Here's what that looks like: > > https://go.dev/play/p/BhARBtthdzJ > > This allows me to trace back the cause across the logs by sorting by time > and filtering for the trace id. Means I only need to log the error once. > The negative here is you have to pass context around for any function that > logs....which is probably most of them when most of those functions don't > need to do cancellation. I suppose you could just do context.Background. > > So that's what I've come up with. I am curious what others have done. > > Thanks, > Joe > > P.S Note yes i know the problem is distributed tracing, that logging is a > poor way to do this, and one should use an observability platform like > honeycomb.io <https://www.honeycomb.io/> to send errors too. But I don't > have a platform. I have slog and i am curious how to make error tracing > work nicely with that. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/3a786e33-cb56-4bf5-8e84-d8bfbda7737en%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/3a786e33-cb56-4bf5-8e84-d8bfbda7737en%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAGPPfg_NwFtTm_%2BZRVbgKCFR7iG85neh%3DUDeCXq1aWVQJgQGZA%40mail.gmail.com.
