3 ms·
1) The idea is that your library should accept the slog logger and use it. The caller would create a logger with a handler that defines how log messages are han
by aleksi 1y ago
1) The idea is that your library should accept the slog logger and use it. The caller would create a logger with a handler that defines how log messages are handled. But there are problems with supported types; see my other comments.
2) It is improved in 1.25. See https://github.com/golang/go/issues/59928 https://github.com/golang/go/issues/59928 and https://pkg.go.dev/testing#T.Output https://pkg.go.dev/testing#T.Output. Now it is possible to update slogt to provide correct callsite – the stack depth should be the same.
- peterldowns 1y ago1) Right, but this is complicated and annoying. Imagine a world where you could just pass your existing logger in, because my library references an interface like `stdlib/logging.GenericLoggerInterface` and slog, zap, zerolog, etc. all implement that! Would be nice! 2) TIL about `T.Output`, thank you, that's great to know about. Still annoying and would be nice if the slog package showed an example of logging from tests with correct callsites. Golang gets so many things right about testing, so the fact that logging in tests is difficult really stands out and bothers me.
- phyrog 1y agoBut that is exactly what slog provides? The a unified interface that can be implemented by other logger libraries. Yes the Logger itself is not the interface, but the Handler it is backed by is.