Skip to content

Conversation

@vermaport
Copy link

To fix #387 and #455 properly, we should defer to future.utils.raise_() if the type of V in raise E, V[, T] cannot be inferred.

vermaport added 2 commits May 7, 2019 21:51
1. Handle the 3-argument version of "raise E, V, T".

2. "raise E, V, T" cannot be statically translated safely in general. If V is
not a tuple or a (number, string, None) literal, then translate "raise E, V, T"
to "from future.utils import raise_; raise_(E, V, T)" and let raise_() handle
determining whether V is an instance of E at runtime.

Fixes PythonCharmers#387 and PythonCharmers#455.
1. Uncomment the Test_raise tests now that support for tracebacks has been
added. Add test_unknown_value() to test for PythonCharmers#455.

2. Run the test_raise_() test now that PythonCharmers#455 is fixed. Add a test for PythonCharmers#387
(raise_(E, V, T) now detects if V is an instance of E and no longer blindly
calls E(V)).
@jmadler
Copy link
Contributor

jmadler commented May 8, 2019

Thanks for doing this! Looks like there's a couple related test failures: test_chained_exceptions_stacktrace and test_single_exception_stacktrace. Could you take a look at those? Are those related to your change?

@jmadler
Copy link
Contributor

jmadler commented May 8, 2019

These are unrelated... Merging, thanks!

@jmadler jmadler closed this May 8, 2019
@jmadler jmadler reopened this May 8, 2019
@jmadler jmadler merged commit a6dccd4 into PythonCharmers:master May 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

raise_ fails to reraise exception which requires arguments

2 participants