Adding Error to log functions

[Gucky]

There was a slightly similar issue (Simplify logging Error types #267) but I would like to give this another twist.

Basically all advanced logging systems accept a textual message and allow to add additional values to better describe the log event.
And also many system allow to explicitly log an Error, not just as part of the message or metadata. Examples: Sentry, Datadog
These service do handle explicit errors in special ways like automated grouping, warning thresholds, incident management...
It's more complex to train these systems to analyze/filter/map the metadata of log events and perform the same routines as with explicit errors.

So I would like to propose to add an additional optional Error to the log functions that then can be send to log services.
Manual extraction of key values from an error, in it's simplest form error.localizedDescription or more complex, is not sufficient to leverage the potential of log services.

Given

let error: Error? = ...
let logger = Logger(label: "com.example")

Expected behavior

logger.error("message", error)

and a signature of the log(...) function of the LogHandler protocol

func log(
        level: Logging.Logger.Level,
        message: Logging.Logger.Message,
        error: Error?, // <<<<<<<<<< new line here
        metadata: Logging.Logger.Metadata?,
        source: String,
        file: String,
        function: String,
        line: UInt
    )

Actual behavior

The given log functions .log(...) or explicit like .error(...) on a logger instance only accept a message and metadata where metadata is a String, or array/dictionary hierarchy where terminal elements are again String.

SwiftLog version/commit hash

v1.5.4

[raviraj-tribe]

Thank you! Looking forward for this!

[one1color]

Would be nice :)

[jefflewis]

I think this would greatly improve the ergonomics of this logging system. So many logging services have special affordances for Error that being able to log.error the actual error and have it end up in the log handler for proper processing seems like a critical need.

As-is, to do this, I have to wrap an error with a CustomStringConvertible conforming error wrapper, and attempt to extract the error from this error. :/