safeString() not so safe about logfmt

[ChrisHines]

Good observation.

The basic structure of safeString was modeled on how the standard library fmt package handles panics. It's been a while since I implemented it here, and I haven't tracked if the fmt package's handling of panics has improved or changed since I looked at it back then, but here is the pertinent code in fmt today: https://golang.org/src/fmt/print.go#L530. At first glance it looks like fmt tries harder to avoid propagating the panic.

I tend to agree with your suggestion that we can and probably should do more here. Would you like to work on a PR to improve this?

[bboreham]

I took a look at fmt/print.go; it will take first the %v format string; if that panics and it was a null pointer then <nil>; otherwise try to print the panic value; if that panics then it re-throws the panic.

I can get similar behaviour by writing s, ok = fmt.Sprintf("PANIC:%v", panicVal), false in the else clause of safeString. Will try to do a PR with this today.

To what extent do you want the decode side to work with panic values? Perhaps they should obviously fail to decode?

[ChrisHines]

That sounds like a reasonable approach to me. If you do submit a PR please make the same improvements to safeError and safeMarshal as well.

I don't think the decode side needs to do anything special. The decoder only returns []byte data for the keys and values it parses. It doesn't interpret the keys or values in any way and I don't think it should start now.

[bboreham]

I submitted a PR.

[ChrisHines]

Yes, you did, and I totally lost track of that. My apologies.

I'll try to review that soon. I've also been thinking about another change to improve the way this package handles invalid keys. So I'd like to work on that and probably release it together with your improvements in v0.4.0.

[AlekSi]

Was it done? Can this issue be closed?

[ChrisHines]

Yes, it was done. #7 was merged. Don't know why the issue didn't get closed. Thanks for the reminder.