When is the Logger.Error vs ErrorHandler use? #3542
Replies: 2 comments 1 reply
-
There is definitely overlap there. The error handler predates the logger, and when the logger was added the error logging feature overlapped with the existing functionality. There was a thought when this was done that the errors passed to the error handler could in theory be "handled", meaning a action might be taken for them, but the logged errors were only intended to be used as a communication of a failure. That said, I don't know if that is truly the case. The error handler errors are asynchronous. The process that produced the error is not easily known, so taking action on its behalf if problematic. Also, the logger could in theory be setup to take actions for errors logged to it even though that is not its intent. I think at this point, we might want to deprecate the error handler in favor of the logger. When systems dump the error handler an error, we give a false impression that something useful might be done with the error. That is less true with the logger, it becomes clearer that the only "useful" thing that is going to happen with the logger is that it will log the error. By removing this dump for errors it will motivate sources to take a close look at errors before giving up and just logging them. |
Beta Was this translation helpful? Give feedback.
-
So as right now, it is kind of "random" when the developer decide to |
Beta Was this translation helpful? Give feedback.
-
otel offers a
otel.SetLogger
andotel.SetErrorHandler
, both of them seem to be called in some Error cases, see https://github.com/open-telemetry/opentelemetry-go/blob/main/internal/global/internal_logging.go#L52 and https://github.com/open-telemetry/opentelemetry-go/blob/main/handler.go#L95Would be good to explain to the user when one is called vs the other. Thanks
Beta Was this translation helpful? Give feedback.
All reactions