[API] Clarify expectations for C++ exceptions, and usage of noexcept methods.

[marcalff]

Several methods in the API are flagged as noexcept.

This is desirable, because adding instrumentation to an application (i.e., calling opentelemetry-cpp apis) should not make the application less stable.

In particular, any failure in the opentelemetry-cpp sdk or exporters should not propagate the exception up, taking the application down.

To comply with the noexcept contract, methods in the SDK implementation should never raise exceptions.

According to clang-tidy reports, this is not always the case.

This part should be revisited, to clarify expectations, and enforce the SDK implementation complies.

cc @msiddhu

[marcalff]

Related:

• [EXPORTER] Ignore exception when create thread in OTLP file exporter. #3012

[msiddhu]

I'll work on this. Currently, there are 20 warnings flagged by clang-tidy as they may raise errors. I'll make a sheet explaining why and will come up with a cleanup. I'm busy this week but will raise a PR by late next week.

[github-actions]

This issue was marked as stale due to lack of activity.

[Andrew-Brock]

Hi @msiddhu, did you get anywhere in generating the spreadsheet for this? I'm interested in the status of it because in the current state, the functions being marked as noexcept ironically make the API more likely to introduce instability due to it now calling std::terminate rather than giving me a chance to handle the exception, especially in the case of the Observable metrics in sdk::metrics::ObserverResultT::Observe where the exception would be off in its own thread.

I also see that in places where this is attempted to be handled, such as in #3012, that the exception handling can also throw exceptions such as when building up the std::stringstream tmp_stream or in the registered LogHandler::Handle, as-per the definition of the OTEL_INTERNAL_LOG_DISPATCH macro.

I'm happy to submit some small PRs to address some but your comment hints that some of these may not be so trivial to fix.

[Andrew-Brock]

I've come across another case where exceptions may be thrown in non-obvious ways in functions marked as noexcept.

Some places constructing a shared_ptr where the object is allocated with new (std::nothrow). In this situation if the allocation fails the pointer will be nullptr, but the very next thing to happen will be the shared_ptr performing another allocation internally for the control block. If the previous allocation failed then there's a good chance that the 2nd allocation will fail too, but this time throwing a std::bad_alloc.

There are several places that do this. 1 example is in Tracer::StartSpan.