zap.Error should check if the error implements ObjectMarshaller first

[nhooyr]

Would be neat to have structured errors.

[akshayjshah]

Our intention with the strongly-typed field constructors was to make the output obvious and predictable. If you'd like this sort of type-sniffing, zap.Any is probably a better fit.

Depending on where you're ingesting your logs, adding this feature as you've described will break indexing in many systems. For example, ElasticSearch becomes very unhappy if one message contains "error": {"foo": "bar"} and another contains "error": {"foo": 42}, since error.foo now has an inconsistent type. The current implementation of zap.Error goes really far out of its way to accommodate a variety of fancy error packages without introducing any type conflicts.

[nhooyr]

Going to close as it has been a long time and I'm not sure if this is relevant anymore.