Not sure what your definition of "supported" is, but I'm afraid you're going to have to bite the bullet and ... gasp ... read the documentation https://pkg.go.dev/log/slog

▲

aleksi 2 days ago | parent [-]

Not sure I understand your sarcasm. I read the documentation, source code, handler writing guide, and issues in the Go repository multiple times over two years, and I use slog extensively. Go is my primary language since r60. I think I know how to read Go docs.

Now, please point me to the place in the documentation that says if I can or can't use a value implementing the error interface as an attribute value, and will the handler or something else would call the `Error() string` method.

My definition of "supported" is simple – I could pass a supported value to the logger and get a reasonable representation from any handler. In my example, the JSON handler does not provide it for the fmt.Stringer.

▲

arccy 2 days ago | parent [-]

https://pkg.go.dev/log/slog#JSONHandler.Handle

> Values are formatted as with an encoding/json.Encoder with SetEscapeHTML(false), with two exceptions.

> First, an Attr whose Value is of type error is formatted as a string, by calling its Error method. Only errors in Attrs receive this special treatment, not errors embedded in structs, slices, maps or other data structures that are processed by the encoding/json package.

So the json handler more or less works as if you called json.Marshal, which sounds pretty reasonable.

▲

aleksi a day ago | parent [-]

I think you missed the “any handler” part. Currently, the types that my library package could use depend on the handler used by the caller. This limits types to an unspecified subset, making things quite impractical.

	▲	arccy 6 hours ago \| parent [-]
		any handler is too broad, maybe my custom handler only logs strings and ignores ints. for a reasonable substitute subset, use the core language types, and implement LogValuer for anything complex.