Address potential unhandled exceptions in OTLP exporters

[herin049]

Is your feature request related to a problem?

Under scenarios when invalid signal-specific objects as passed to OTLP exporters, an unhandled exception can be thrown which directly violates the requirements outlined by the spec: https://opentelemetry.io/docs/specs/otel/error-handling/

OpenTelemetry implementations MUST NOT throw unhandled exceptions at run time.

Two ways in which this issue can be addressed are:

1. Update encode_metrics/encode_traces/encode_logs to NOT raise an exception, and instead log an error when unexpected data is encountered
2. Update OLTP metric exporters to handle the exception, logging the error and returning an export failure result

For additional context see #4996.

Would you like to implement a fix?

Yes

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[pmcollins]

Hi, thanks for opening this. My preference is for the encoder to not throw an exception on an unexpected value, but rather log it, skip the field, and continue encoding. That way we don't fail the entire batch, and all callers get the safe behavior automatically. Interested in other thoughts though.

[herin049]

Based on discussions in the SIG meeting, the recommended approach is to still raise an exception and report a batch failure in the exporter itself.