The question of how to pass loggers around was discussed at significant 
length in GitHub, and drew a lot of strong opinions. More so than other 
standard library stuff, any particular piece of the slog API is maybe less 
an eager endorsement of best practices, but more about matching what exists 
in other popular logging packages. Particularly context/logger usage was 
sort of a bright line division, I think a fair summary is that it's not an 
option for some developers, and for others it's admittedly a trade-off that 
makes sense because contexts are already plumbed through everything.

The jww package begins to address the question by using a configurable 
global logger, like slog.Default. Before moving away from that - and it 
might be enough, really, it's greatly simplifying - I think it might be 
worth working out what kinds of structure is already latent in the 
application. Personally I've come to prefer implementing the LogValuer 
interface and global loggers, except when there are really easy/obvious 
places to use child loggers. But, there are lots of opinions and lots of 
real-world examples of different approaches working out as well.
On Friday, March 28, 2025 at 5:58:51 AM UTC-7 cpu...@gmail.com wrote:

> I'm in the process of converting our application (evcc.io) from using 
> spf13/jwalterweatherman for logging to log/slog. One current pain point is 
> passing loggers around the application and deriving child loggers. With 
> using slog there are various options for doing that:
>
> Passing loggers:
>
>    - pass parent logger as parameter
>    - pass a context and retrieve the parent logger from context value
>    
>
> Passing log attributes/groups to child loggers:
>
>    - assign them to loggers and pass them via the logger (see before- 
>    either as parameter or context value)
>    - assign them to context and retrieve them from context value for 
>    assigning to the child logger
>    
> Not sure those questions are clear enough, but let's try: are there 
> experiences what works "best" in larger applications?
>
> Cheers,
> Andi
>
>

-- 
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 visit 
https://groups.google.com/d/msgid/golang-nuts/fea26fa0-e865-4f86-9989-47094eb365c2n%40googlegroups.com.

Reply via email to