Should the logs be emitted by default?

[pellared]

Currently the default ErrorHandler logs the errors to stderr. It means that the instrumented application can have a different visible output for the user.

Is it OK? Is any other language doing the same?

Related draft PR: #2416

[MadVikingGod]

Why do we do this? Because of how go is built there is no central logging package like Log4J or Log4Net etc that gives library writers both a flexible API, and a central location for libraries like ours to log to(1)(2). I think the main reason is that as a culture we return an error over logging messages. But that gives us as non-core logic library (3) writer a problem, how do we report problems in secondary code?

Take for example if we have an exporter that is incorrectly configured, like pointing at a misspelled domain/service. In this case, the core business logic can and should work fine, so there shouldn't be errors in that code, but at the same time we don't want this to be a silent fail.

The question I would have to this is "If we by default don't emit via stderr, then how does a consumer know that something is wrong?"

(1): There is the stdlib log, but it because it's API is based on formated strings library don't coordinate their different output formats
(2): There are logging libraries like zap, and logrus but they are not compatible with each other, and choosing one could prevent us from being included in applications using something else.
(3): Opentelemtry is a library that doesn't solve a core business logic problem, but a problem external to the core flow of code,

[pellared]

@MadVikingGod Thanks for your reply.

You convinced me that it is more convenient to log than emit nothing. Waiting for a follow-up PR after #2343 is merged. Closing.