-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
Description
Proposal
Currently most transport implementations accept a logger instance. When a transport level error occurs, they are usually handled by a code like this:
if err != nil {
s.logger.Log("err", err)
s.errorEncoder(ctx, err, w)
return
}
I'm proposing to add a new concept in addition to/replacing server loggers: error handlers.
With an error handler in place, the above code would look like this:
if err != nil {
s.errorHandler.Handle(err)
s.errorEncoder(ctx, err, w)
return
}
The interface for such handler:
type ErrorHandler interface {
Handle(err error)
}
Reasoning
While logs might be the most common target of error events, error can also be considered a distinct domain in which developers might want to take different actions than logging, for example sending the error (with context, like stack trace) to an error tracking service or triggering some sort of alert.
Of course, logs remain a natural target (and an error handler which eventually logs the error would make perfect sense), but it takes extra effort to "reverse engineer" every log to see if it contains an error to handle it differently.