-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
handle logger creation failures #52
Conversation
/** | ||
* Used for testing purposes. | ||
*/ | ||
internal fun resetShared() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
where do you use this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nowhere, leftover that I thought I removed. Removing for real time time...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually, re-added it to fix flakiness of CaptureTest.kt
tests
platform/jvm/capture/src/main/kotlin/io/bitdrift/capture/Capture.kt
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
by always catching at construction time you might've "fixed" other cases where the context.getSystemService
might be null (see BIT-3712). Should be ok although we now incur the cost of shutting down the entire logger when the better solution would be to only shutdown the dependent ListenerLogger
…re.kt Co-authored-by: Miguel Juárez López <[email protected]> Signed-off-by: Rafał Augustyniak <[email protected]>
Make platform layer handle cases where a Rust call to create a logger fails.
The way the logic works is that after the first time
Logger.configure
fails the consecutive attempts to configure the logger are no-ops. There is a public API change introduces in this PR on Android.Logger.configure(...)
method returns an optionalLoggerIntegrator
object that used to be non-optional. For this reason, the next release will be 0.15.0.Fixes BIT-3752