-
-
Notifications
You must be signed in to change notification settings - Fork 432
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
Recover Jetpack Compose stacktraces #2070
Comments
@romtsn do you know if there's a way to trace back to the original stack trace frames? e.g. #1524 (comment) |
Yeah the problem is the usage of lambdas/anonymous classes for all of them I guess. I feel like this can be done through bytecode manipulation (e.g. getting the argument name for lambda), but not sure if there's a silver bullet for all. |
We should check if there's a library for doing this. If we can find a workaround for the meantime we should add it to the troubleshooting page. There's a flag in the coroutines library that makes it print more verbose stack traces. This could help. |
We've decided it's not worth the effort, and it's not clear what should be the outcome. At the moment, linenos are still correct and show you exactly where the error has happened. When #633 is in place, this should help even more and show surrounding code. |
Problem Statement
Since compose is a declarative UI framework, there's a big usage of lambdas, which get transformed into anonymous classes, therefore stackframes that contain compose code do not really look helpful (besides the file name and line numbers, it's hard to figure out what's going on). For example:
It'd be nice if we can recover the stackframes and make them pretty by including the actual lambda argument names (in this example it'd be
NiaFilterChip$onClick
andTopicRoute$onFollowClick
instead ofNiaFilterChip$1$1
andTopicRoute$1
respectively).Solution Brainstorm
Probably would require some logic on the bytecode level (either through SAGP or a jvm-agent) to collect the information about lambdas and add them to the proguard-mapping file so they get correctly interpreted on the product side (or maybe we'd require some new logic on the product side as well).
https://github.com/Guardsquare/kotlin-metadata-printer might be useful to read kotlin's metadata.
The text was updated successfully, but these errors were encountered: