Skip to content
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

handle panics in logr.Marshaler.MarshalLog #52

Merged
merged 1 commit into from
Feb 16, 2022

Conversation

pohly
Copy link
Contributor

@pohly pohly commented Feb 15, 2022

The function might panic. The conclusion in
go-logr/logr#130 was that the logger should
record that.

zapr only needs to do that when it calls MarshalLog. Strings and errors are
handled by zap.

For the sake of simplicity no attempt is made to detect the reason for the
panic. As zapr cannot replace the key, it uses the same replacement value as
funcr because that stands out a bit more compared to the value used by zap.

/assign @thockin

zapr_test.go Outdated
{
msg: "nil marshaler",
// Handled by our code: it just formats the error.
format: `{"ts":%f,"caller":"zapr/zapr_test.go:%d","msg":"nil marshaler","v":0,"obj":"<panic: runtime error: invalid memory address or nil pointer dereference>"}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm on the fence whether this should be consistent with funcr or with zap (see below).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would make it consistent with the underlying library, I think. I don't like the pattern, but I can see the argument. IMO the user chose to use zap, they should experience zap's design decisions (for better or worse)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay. I've updated the handling accordingly.

The function might panic. The conclusion in
go-logr/logr#130 was that the logger should
record that.

zapr only needs to do that when it calls MarshalLog. Strings and errors are
handled by zap.

For the sake of simplicity no attempt is made to detect the reason for the
panic. In case of a panic, the key is replaced by "<key>Error" and the value
with "PANIC=<panic reason>". This is consistent with how zap handles panics.
@thockin thockin merged commit df10f47 into go-logr:master Feb 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants