Replies: 1 comment 2 replies
|
I guess this rule is necessary, because there's no server-side deobfuscation of the exception titles on Firebase. This is mostly relevant if you have custom exception types that you'd like to keep from being obfuscated (all default types like IllegalArgumentException are part of Android/JDK already). Sentry tries to deobfuscate this server-side but there are some rough edges, so sometimes we also have to provide rules like this ourselves:
|
|
Thanks for this answer! Does this mean, that #711 is not relevant anymore and that Sentry backend should be able to reliably deobfuscate the class names of exceptions (also for custom exceptions)? Was this the reason to drop this rule in the current Gradle plugin and Android libs (it was previously also present there)? Since we can not know or control in which degree other libraries make use of custom exceptions, we like to make sure to not add noise to our reports with obfuscated exception names. So is it advisable to add the |
I guess this rule is necessary, because there's no server-side deobfuscation of the exception titles on Firebase. This is mostly relevant if you have custom exception types that you'd like to keep from being obfuscated (all default types like IllegalArgumentException are part of Android/JDK already). Sentry tries to deobfuscate this server-side but there are some rough edges, so sometimes we also have to provide rules like this ourselves:
-keepnamesshould be enough in this case as we only are interested in the name of the class.