Die on errors during import #19
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Given that the dependencies will be specified in the distribution this feels appropriate enough (no different than any other dependency missing). If there's ever another exporter, you can revisit how this is done. |
The [specification] states that > OpenTelemetry implementations MUST NOT throw unhandled exceptions > at run time. but it also says that > The [...] SDK MAY _fail fast_ and cause the application to fail on > initialization, e.g. because of a bad user config or environment, > but MUST NOT cause the application to fail later at run time, e.g. > due to dynamic config settings received from the Collector. Before this change, the SDK was not "failing fast" for the sake of application stability. However, this could result in setups that were misconfigured but kept running, giving the user the incorrect impression that things had gone according to plan. This made debugging harder. The situation was made worse because before 56d6689 (which added the OTLP exporter as a dependency of the SDK) because in that case the SDK was defaulting to a broken configuration state, and failing silently. This is no longer the case, so any remaining cases of a misconfigured SDK are bugs that should be addressed, and are probably going unnoticed by users. Fixes #18, but at what cost? [specification]: https://opentelemetry.io/docs/specs/otel/error-handling/#basic-error-handling-principles
|
I'm not a fan of adding exceptions, but I think this is a change for the better. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The specification states that
but it also says that
Before this change, the SDK was not "failing fast" for the sake of application stability. However, this could result in setups that were misconfigured but kept running, giving the user the incorrect impression that things had gone according to plan. This made debugging harder.
The situation was made worse because before 56d6689 (which added the OTLP exporter as a dependency of the SDK) because in that case the SDK was defaulting to a broken configuration state, and failing silently. This is no longer the case, so any remaining cases of a misconfigured SDK are bugs that should be addressed, and are probably going unnoticed by users.
Fixes #18, but at what cost?