Basically all advanced logging systems accept a textual message and allow to add additional values to better describe the log event.
Any 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.
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. Any 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
Expected behavior
and a signature of the log(...) function of the LogHandler protocol
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