对于throw指令被catch后再return，会导致pop多次，我comment了一个实现try-finally的链接

对于throw后catch的路径，end代码被调用了多次，也就是pop了多次，虽然会比较start时存入的methodId(foo)，对于不相等的，则不上报。但是已经pop出来的，却没有再push回去，会导致整个堆栈均无法正确end，导致错乱，只有等这一波堆栈全pop出来后重新来一次。

foo() {
(start_foo)
try {
(end_foo_1)
throw e;
} catch (e) {
}
(end_foo_2)
return ;
}

对于sql慢速日志，sql由于固定在一个特定的方法里，而且不会存在窃套，其实堆栈深度最大也就1，而且使用了独立的堆栈，问题倒不大。

相关代码：
ProfMethodAdapter. visitInsn(insn) :74
case Opcodes.RETURN:
case Opcodes.ATHROW:
this.visitLdcInsn(mMethodId);
this.visitMethodInsn(INVOKESTATIC, "com/taobao/profile/Profiler", "End", "(I)V");
break;

Profiler. End(methodId): 116
thrData.stackNum--;
long[] frameData = thrData.stackFrame.pop();
long id = frameData[0];
if (methodId != id) {
return;
}

Start with ProfMethodAdapter.visitInsn at the cited line and Profiler.End at line 116, then trace the throw/catch/return path shown in the issue. Review the try-finally implementation link from the comment and verify that stack frames remain balanced and the method is ended correctly after the exception path.

Written by the indexing model from the issue text.