-
Notifications
You must be signed in to change notification settings - Fork 7.3k
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
When using suspending async/await, stacktrace contains no application code #3474
Comments
Requires |
That is unfortunate, I did not notice it still has Is there anyway we could do this locally - like via some Because right now, we are having crashes with stacktrace without any app code in our crash console with no way to find where they are coming from. |
This comment has been minimized.
This comment has been minimized.
Here is a 'small but ugly' workaround that I use:
And then in all my catch blocks I invoke wrapToBeTraceable() in the exception And then I add it to the uncaught exceptions handlers as well
As I said its ugly, but I cant see any other options :-| |
I change net request to coroutine , My code also happened , CoroutineExceptionHandler and try cach all can not solve , I am going to collapse |
This issue is still occurring on com.squareup.retrofit2:retrofit:2.9.0 Fatal Exception: retrofit2.HttpException: HTTP 422 Unprocessable Entity My stacktrace does not refer to any application code. Are there any workarounds? |
Yes @Red7M , you can surround all calls to retrofit in try/catch blocks.
its ugly but the only way I can see to get at least some useful information. |
Any updates on this? @JakeWharton |
Use an OkHttp interceptor and look up the Updates will be posted as comments or status changes on the issue. |
Very nice, thank you! That was tremendously helpful :) If anyone here has the same problem, here is our implementation of such an interceptor:
|
tag.arguments() may contain PII data and probably shouldn't be logged to firebase if you care about that. For us it was enough to take tag.method().toString() to get useful information about what triggered the request. And then we just sent it as a log so that it will be uploaded to Crashlytics only if a crash is logged. It will log something like this: Network request called from: public abstract java.lang.Object foo.bar.SomeClient.doNetworkRequest(java.lang.Double,kotlin.coroutines.Continuation)
|
To prevent the app from crashing, I incorporated the following code into the application that inherits from the base application class. Thread.setDefaultUncaughtExceptionHandler { thread: Thread, throwable: Throwable -> |
Can be reproduced by simple test:
By default the stacktrace will look like:
This is not very helpful, as we don't know which call caused the exception.
Attempt at fixing can be found in #3475, comments appreciated. That would lead to following trace:
The text was updated successfully, but these errors were encountered: