handle corrupted bytecode #251
Conversation
|
I'm tempted to not merge this change. Mostly, bytecode corruption would be a problem caused by tools doing the wrong thing (in this case, javassist/realm) and since these aren't standard and sort of require development anyway, I would expect one to debug it by throwing the message in manually. |
src/NativeFinder.scala
Outdated
| val r = new ClassReader(in) | ||
| r.accept(x, 0) | ||
| } catch { | ||
| case e: Exception => throw new IllegalArgumentException(s"NativeFinder processing `$entry` went wrong, bytecode is corrupted") |
There was a problem hiding this comment.
The error should be more along the lines of
throw new IllegalArgumentException(s"Failed to process bytecode for$entry", e)
There was a problem hiding this comment.
Sure, will update if you gonna merge it in.
|
What was most striking to me is that javasist silently messed up with bytecode and that was discovered latter on in a build process. I will probably look into this again latter. Probably you right, if someone has been done something to bytecode outside of android-plugin, responsibility is on them. But still I would be more chill to have this additional level of clarity here. |
aafa
force-pushed
the
NativeFinder-add-exception
branch
from
2ff7eb1 to
9bb61f2
Compare
|
Commit updated. |
|
I guess it doesn't hurt, might as well merge |
2 participants
Adding some more details on why build failed to be processed