New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
log/slog: handle panics in LogValuer.LogValue #59141
Comments
I think you're right. The situation is analogous to a panic in |
This proposal has been added to the active column of the proposals project |
Based on the discussion above, this proposal seems like a likely accept. |
FWIW I don't expect to sway anything but I've been repeatedly frustrated by the So, personally, I agree that this is analogous to |
@Merovius, I'll try to include some context in the string. |
No change in consensus, so accepted. 🎉 |
Change https://go.dev/cl/484097 mentions this issue: |
If a LogValue call panics, recover and return an error instead. The error contains some stack information to make it easier to find the problem. A number of people complained that panics in fmt.Formatter.Format functions are hard to debug because there is no context. This is an example of the error text: LogValue panicked called from log/slog.panickingLogValue.LogValue (/usr/local/google/home/jba/repos/go/src/log/slog/value_test.go:221) called from log/slog.Value.resolve (/usr/local/google/home/jba/repos/go/src/log/slog/value.go:465) called from log/slog.Value.Resolve (/usr/local/google/home/jba/repos/go/src/log/slog/value.go:446) called from log/slog.TestLogValue (/usr/local/google/home/jba/repos/go/src/log/slog/value_test.go:192) called from testing.tRunner (/usr/local/google/home/jba/repos/go/src/testing/testing.go:1595) (rest of stack elided) Fixes golang#59141. Change-Id: I62e6ff6968d1aa34873e955c2d606d25418a673b Reviewed-on: https://go-review.googlesource.com/c/go/+/484097 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Alan Donovan <adonovan@google.com> Run-TryBot: Jonathan Amsterdam <jba@google.com>
If a LogValue call panics, recover and return an error instead. The error contains some stack information to make it easier to find the problem. A number of people complained that panics in fmt.Formatter.Format functions are hard to debug because there is no context. This is an example of the error text: LogValue panicked called from log/slog.panickingLogValue.LogValue (/usr/local/google/home/jba/repos/go/src/log/slog/value_test.go:221) called from log/slog.Value.resolve (/usr/local/google/home/jba/repos/go/src/log/slog/value.go:465) called from log/slog.Value.Resolve (/usr/local/google/home/jba/repos/go/src/log/slog/value.go:446) called from log/slog.TestLogValue (/usr/local/google/home/jba/repos/go/src/log/slog/value_test.go:192) called from testing.tRunner (/usr/local/google/home/jba/repos/go/src/testing/testing.go:1595) (rest of stack elided) Fixes golang#59141. Change-Id: I62e6ff6968d1aa34873e955c2d606d25418a673b Reviewed-on: https://go-review.googlesource.com/c/go/+/484097 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Alan Donovan <adonovan@google.com> Run-TryBot: Jonathan Amsterdam <jba@google.com>
For the sake of making logging resilient against bugs it would be good to handle panics in
Value.Resolve
when callingLogValuer.LogValue
. Currently this is not handled, causing the entire program to crash.Found when adding slog support to zapr. One of the existing test cases covers this case by using a nil pointer for a type that doesn't support that:
A better implementation of
LogValue
of course shouldn't crash, but bugs are bugs... 🐛 🐞cc @jba
The text was updated successfully, but these errors were encountered: