-
Notifications
You must be signed in to change notification settings - Fork 1
Improved fallback mechanism when user is not using hilt/dagger #43
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
Conversation
true | ||
} catch (e: ClassNotFoundException) { | ||
SDKLogger.logger.logDebug {"Hilt is not available"} | ||
SDKLogger.logger.logError { "Hilt is not available: ${e.message}" } |
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.
Do we want to log this as an error or as a debug? I feel like it is almost expected that users will fall into this path and we shouldn't emit errors for expected workflows.
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.
Agree. will update it
ea85776
to
ef5ccdf
Compare
false | ||
} catch (e: Exception) { | ||
// Catch any unexpected issues during class detection | ||
SDKLogger.logger.logDebug { "Error while checking Hilt availability: ${e.message}" } |
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.
why this is logged as Debug not err ?
} | ||
} catch (e: Exception) { | ||
// Handle unexpected errors during initialization | ||
SDKLogger.logger.logDebug { "Error initializing ChatSession: ${e.message}" } |
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.
Is this as debug statement correct?
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.
Yes we aim to print it as a debug which won't interrupt the flow
Issue Number:
Description:
What are the changes? Why are we making them?
Functional backward compatibility:
Does this change introduce backwards incompatible changes? [YES/NO]
Does this change introduce any new dependency? [YES/NO]
Testing:
Is the code unit tested?
Have you tested the changes with a sample UI (e.g. Android Mobile Chat Example)?
List manual testing steps:
Here are a list of manual test cases to run through: