Metrics instances can be created by direct instantiation

[ocelotl]

From the spec:

New Meter instances are always created through a MeterProvider

In our SDK, Meter (and other classes) can be instantiated directly, by importing the SDK Meter class and instantiating it, bypassing the MeterProvider. This is relevant to error handling, if we allow Meter to be instantiated directly, it may raise errors if the user passes bad parameters. If such thing happened using MeterProvider, the get_meter method could catch this errors and return a NoOpMeter.

[srikanthccv]

/s/meter/tracer/g - Same applies, we don't do anything to prevent this from happening.

[lzchen]

We can do something similar as we did for spans? Also if we add this behavior for the tracer, would that be considered breaking?

[srikanthccv]

Also if we add this behavior for the tracer, would that be considered breaking?

Yes, but I do not expect anyone to be directly instantiating it. IMO any changes that do not really fix any buggy behaviour but just move things around for the the sake of spec compliance is breaking. This is also why we can't address this issue #2463 without breaking user systems.

[ocelotl]

Also if we add this behavior for the tracer, would that be considered breaking?

Yes, but I do not expect anyone to be directly instantiating it. IMO any changes that do not really fix any buggy behaviour but just move things around for the the sake of spec compliance is breaking. This is also why we can't address this issue #2463 without breaking user systems.

Are you in favor of closing this issue, then, @srikanthccv?

[srikanthccv]

I was thinking may be we can ensure instruments are not created directly at least. What do you think?

[ocelotl]

Ok, I can work on that 👍

[ocelotl]

Sorry, I just noticed that you have assigned this to yourself. If you want/need I can take it, just let me know.