Invert order in which visitTryCatchBlock adds to the exception table
When calling visitTryCatchBlock, it is currently implicit that the visited
handler is added to the bottom of the method's exception table. At the same
time, it is required that a visitTryCatchBlock method is invoked before
visiting the label that starts the handler. This makes a common ASM use-case
difficult to solve:
When using ASM to wrap a method or parts of a method within a try-catch-block,
any surrounding handler is always triggered first and can cause unexpected
side-effects such as this user probably encountered:
http://stackoverflow.com/questions/23491902/adding-try-catch-block-in-bytecode-through-asm
I think that it would be more intuitive if a visitedTryCatchBlock would be
added to the top of the exception handler table. This would allow to
dynamically create nested handlers. Today, these nested handlers need to be
known at the beginning of the method because the deepest handler must be called
first to end at the top of the exception table.
Consider a scenario where two method visitors add an exception handler entry
upon discovering a method foo:
try {
try {
foo();
} finally {
instrumentation1();
}
} finally {
instrumentation2();
}
When chaining to visitors the first visitor would add an exception table entry
and a label, call the super method and then add the completion label and
handler label as well as logic. The nested method visitor would do the same but
its handler would never be triggered as the handler comes at second place in
the generated exception table.
Inverting the order entries are added to the table would solve this problem and
I think it would also be more intuitive. (This could be achieved
backwards-compatible by adding a new API version to Opcodes and make the
behavior dependant on this version.)