-
Notifications
You must be signed in to change notification settings - Fork 20
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
Improve error reporting of interpreter fallback #147
Comments
In fact, we do that, see optapy/jpyinterpreter/tests/test_functions.py Lines 266 to 286 in 3c35ef7
optapy/jpyinterpreter/src/main/python/python_to_java_bytecode_translator.py Lines 227 to 300 in 3c35ef7
optapy/jpyinterpreter/src/main/python/python_to_java_bytecode_translator.py Lines 1220 to 1224 in 3c35ef7
try...except (and hence why it is caused by optapy annotations which directly call translate_python_class_to_java_class to get the superclass needed)
|
Thanks for the pointers. They don't show me the error messages that we output if/when this happens, though. (We want people to tell us of these errors, don't we? Even if we handle them properly by falling back.) |
The error situation can definitely improve. I am planning in the future to return a |
Ok, I updated the title of this issue. |
jpyinterpreter
is a very complex piece of code. It would be naive to think that it implements every little nuance of Python bytecode correctly. (Case in point: #146.)The current behavior is that such issues throw an exception, and the user is effectively locked out of using OptaPlanner. I am proposing that we implement a different behavior instead - we log an error, and fall back to unoptimized version. Slower performance beats no performance 100 % of the time.
The text was updated successfully, but these errors were encountered: