Skip to content
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

Exception in nested try-catch suite is 'leaked' to another enclosing try-catch suite #900

BPYap opened this issue Aug 8, 2018 · 1 comment


None yet
2 participants
Copy link

commented Aug 8, 2018

When an exception is raised from a try-catch suite enclosed in another try-catch suite and both suites are trying to catch exception of same type, the exception will be passed directly to the outer suite instead of propagate outwards from inner suite. e.g:

        raise TypeError
    except TypeError as e:
        print("handled by first except")

        raise TypeError
    except TypeError as e:
        print("handled by second except")
except TypeError as e:
    print("handled by outer except")

The correct output should be:

handled by first except
handled by second except

But voc produced the following output:

handled by outer except

So I did some investigations on what is causing this behavior-- something to do with the Exception table generated by JVM. Below is the Exception table generated from the example code above:

    Exception table:
       from    to  target type
          26   154   157   Class org/python/exceptions/TypeError
          26    37    40   Class org/python/exceptions/TypeError
          90   101   104   Class org/python/exceptions/TypeError

The outer exception handler is placed on top of the Exception table, so when TypeError is thrown, this entry is used by the JVM to resolve exception. The code execution will be redirected to offset 157 (the outer catch handler), bypassing the inner catch handler.

@freakboy3742, is this a bug in the JVM or can we somehow "sort" the Exception table by the label to in voc during transpilation?

BPYap added a commit to BPYap/voc that referenced this issue Aug 8, 2018

freakboy3742 added a commit that referenced this issue Aug 11, 2018


This comment has been minimized.

Copy link

commented Mar 5, 2019

Have you tried enumerate "e" with a number? Or Have putting your inner try-blocks in triple-quoted blocks inside an "exec" function call?

It appears like it interprets the call to jump to the end of the outer most try-block and responded to its exception handler due to parsing/translation issues. It may also have an issue with an internal ProgramCounter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.