This avoids obscuring the relevant stacktrace when a Java exception is
thrown while evaluating JRuby scripts. For instance, if one of the
DataStore methods called via $db throws a NullPointerException, the user
will only see: SCRIPT ERROR java.lang.NullPointerException ***
with no additional information. They won't see a Ruby backtrace, because
the interpreter did not terminate in response to a Ruby exception, and
they won't see the Java backtrace because Datavyu only shows the
exception message.
In addition, the eval("load 'Datavyu_API.rb'") call has no effect,
because the script context is configured to clear all variables after
each invocation.
Lastly, instead of parsing the console output of JRuby to get the stack
frames, I'm setting the filename in the scripting context and then
looking for it in the Java stacktrace under the "RUBY" classname.
TheoWolf
commented
3 years ago
363
This avoids obscuring the relevant stacktrace when a Java exception is thrown while evaluating JRuby scripts. For instance, if one of the DataStore methods called via $db throws a NullPointerException, the user will only see: SCRIPT ERROR java.lang.NullPointerException *** with no additional information. They won't see a Ruby backtrace, because the interpreter did not terminate in response to a Ruby exception, and they won't see the Java backtrace because Datavyu only shows the exception message.
In addition, the eval("load 'Datavyu_API.rb'") call has no effect, because the script context is configured to clear all variables after each invocation.
Lastly, instead of parsing the console output of JRuby to get the stack frames, I'm setting the filename in the scripting context and then looking for it in the Java stacktrace under the "RUBY" classname.