Improve error reporting of interpreter fallback
triceo opened this issue · comments
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.
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 CompliationResult
instead of the raw Java class. The CompliationResult
would have fields for errors and warnings (ex: potential None reference, type mismatch, missing method/field, etc). The translator can then report not just mistranslation errors (our errors) but also user errors.
Ok, I updated the title of this issue.