Ergonomic Reporting of std::error::Error

[theduke]

Feature Request

Find some more ergonomic way to report std::error::Error values.

Crates

• tracing

Motivation

Logging a type that implements std::error::Error is currently quite awkward.
Value is only implemented for dyn std::error::Error.

That means logging a concrete type involves awkward type gymanstics for something that is a very common operation.

(unless I'm missing some trick here...)

EG:

// Inline
info!(error = &err as &dyn std::error::Error, "msg");

// Helper variable
let error: &dyn std::error::Error = &err;
info!(error, "msg");

Proposal

Not sure what would be the best way to implement this.
A generic default impl is probably out of the question without specialization.

The most straight-forward solution would probably be a new formatter sigil, eg !.

warn!( error = !err, "msg");

[lilyball]

A related issue is this is only implemented for dyn Error + 'static but it should also have implementations for dyn Error + Send + 'static, dyn Error + Sync + 'static, and dyn Error + Send + Sync + 'static, as those are all unique types.

As an example of where this is annoying, if I have an eyre::Report, it derefs to dyn Error + Send + Sync + 'static, but I can't say info!(err = &*err, "foo"), I still have to say info!(err = &*err as &dyn std::error::Error, "foo") just to drop the Send/Sync bounds.

[lilyball]

record_error should probably also drop the 'static bound, we don't require other recorded types to be 'static so we should be able to record non-static errors too.

[hawkw]

record_error should probably also drop the 'static bound, we don't require other recorded types to be 'static so we should be able to record non-static errors too.

The 'static bound is intended to permit downcasting the error, which would not be possible otherwise.

[lilyball]

Ahh right, downcasting relies on TypeId and that's only available for 'static.

[hawkw]

Right, this is also why the standard library deprecated Error::cause in favor of Error::source, which returns an Option<&(dyn Error + 'static)>. In general, I think it's normally a standard practice to avoid non-'static Errors for this reason. We could consider adding support for errors that are not valid for the 'static lifetime, but if we did this, it would probably have to be via a separate method or something, because we definitely don't want to remove the ability to downcast errors in the common case.