Verify compliant metric SDK specification implementation: Numerical limits handling

[MrAlias]

• [x] Identify all the normative requirements, recommendations, and options the specification defines as comments to this issue
• [x] Ensure the current metric SDK implementation is compliant with these normative requirements, recommendations, and options in those comments.

[pellared]

The SDK MUST handle numerical limits in a graceful way according to Error handling in OpenTelemetry.

From: https://github.com/open-telemetry/opentelemetry-specification/blob/v1.21.0/specification/error-handling.md#basic-error-handling-principles

OpenTelemetry implementations MUST NOT throw unhandled exceptions at run time.

The [...] SDK SHOULD provide safe defaults for missing or invalid arguments.

Whenever the library suppresses an error that would otherwise have been exposed to the user, the library SHOULD log the error using language-specific conventions.

The specification only calls out aggregation_cardinality_limit which is not implemented (it is experimental).

[pellared]

If the SDK receives float/double values from Instruments, it MUST handle all the possible values. For example, if the language runtime supports IEEE 754, the SDK needs to handle NaNs and Infinites.

Exploratory tested with NaN, Inf+, Inf-. Results: https://github.com/open-telemetry/opentelemetry-go/pull/4209. Everything works as expected.

[pellared]

It is unspecified how the SDK should handle the input limits. The SDK authors MAY leverage/follow the language runtime behavior for better performance, rather than perform a check on each value coming from the API.

This is explicitly not normative.

[pellared]

It is unspecified how the SDK should handle the output limits (e.g. integer overflow). The SDK authors MAY rely on the language runtime behavior as long as errors/exceptions are taken care of.

This is not normative. However, there is a requirement that "OpenTelemetry implementations MUST NOT throw unhandled exceptions at run time." that needs to be checked.

Integer overflows are not causing runtime panic at runtime. The value is simply overflown. Reference: https://go.dev/ref/spec#Integer_overflow

[pellared]

It looks like we comply with this fragment of the specification.

@MrAlias Can you please double-check and close if you agree with my verification?

[MrAlias]

LGTM