[ljm]

Go's approach has been to treat errors as a linked list, and thus one would explicitly create a chain of errors by wrapping each one as it passes up the stack. The end result would be an error like 'Error Z: Error Y: Error X', as each error in the list is 'unwrapped'.

The lack of any kind of caller information when creating an error makes it quite important to write decent error messages, which I think is actually quite hard to do.

At the same time I think it depends on what you're building: a library should have good errors (ideally well-typed ones too), but in an application you'd benefit from adding logging at each point in the stack (which can then contain caller information like file and line number) rather than just doing the logging at a system boundary; maybe set it at debug level. Then use tracing for the rest of it (for extra visibility in stuff like Sentry).

At least, I feel like that's how you'd be encouraged to do it in Go considering the opinions of Go's creators.