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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
[embed] refactor (JSR223) exception wrapping #6457
Conversation
also throw on missing or empty method name ...
58fdc84
to
b5a8b11
Compare
f4097fe
to
e56c28d
Compare
should not expect behavior will null reader/filename
Pre-review comments...
Since this is still used by default in ScriptingContainer invokes I think we probably can't deprecate it unless we also deprecate the invoke paths that use it. This leads to the second question...
I am less excited about adding to the factory API than I would be about deprecating current invoke/eval methods in favor of new ones. Those eval methods have not been touched in over a decade and there are better forms of invoke and eval we could add as a new API. That would allow us to deprecate the old paths and provide a migration path away from old patterns. For purposes of this PR, which mainly seeks to reduce the wrapping happening inside the javax.script API, I would say let's not deprecate InvokeFailedException until we can work on making a new ScriptingContainer API that doesn't use it at all. |
setting system properties in one does not leak to other
e534f56
to
840c922
Compare
still find some (untested) cases related to exceptions - there is proper |
105a8d5
to
8dfbe77
Compare
when pre-parsing (compiling) scripts the parser will assume potential loval variables to be method calls, since the eval scope won't provide any local variable names (compared to directly eval-ing with bindings passed in). see jrubyGH-5876
8dfbe77
to
097186f
Compare
* master: (235 commits) Arity-split Array#sample Handle arity errors better in sample Arity split and handle bad kwargs in shuffle Spec appears to be intermittently failing Adjust specs for unpack/pack 'j and 'J' support Implement unpack/pack 'j' aand 'J' Restore getrlimit and frozen string tags Restore two pack tags mistakenly removed Sweep passing library tags Sweep passing UnboundMethod tags Sweep tags for TracePoint Sweep passing Time tags Sweep passing Process tags Sweep passing ObjectSpace tags Sweep passing tags for Thread and friends Sweep passing tags for Hash, Marshal Sweep passing Kernel tags Sweep passing tags for Env, Exception, File, IO Sweep passing tags for core numerics Sweep passing Comparable tags ...
馃煝 after merge, note that the PR does NOT resolve #5876 but we at least explicitly test existing behaviour with compiled scripts. |
This can be merged any time and I will look into enhancing the 223 exception messages with file and line info once it has landed (#6560). |
seems it's been a while since this code was visited, there's some cleanup/refactoring along the line.
the motivation is trying to use
javax.script
APIs and finding things a bit cumbersome, namely:Ruby raises get double packed into an "embed failed exception" which than is wrapped into a
javax.script.ScriptException
(when usingScriptEngine#invokeMethod
),believe this is just ineffective - e.g. Nashorn actually exports it's specific exceptions and doesn't always wrap.
JRuby, since 9.2, has the Java chain for Ruby exceptions - which is very useful with JSR223 (unless it's burried to causes down the line), JRuby should really consider doing a breaking change here ... as proposed.
also, any throwable gets wrapped (into a
InvokeFailedException
) evenjava.lang.Error
s, which feels weird.null returns around JRuby's JSR-223 script engine impl, e.g. it was legit to
callMethod("", foo)
with an empty name that pretty much doesn't actually invoke a Ruby method - the impl simply returned null (and this was actually tested 馃敨).(silent) exception printout(s) and runtime std-out printing ruby exceptions by in embed mode
CHANGE SUMMARY:
InvokeFailedException
,RaiseException
s will simply by wrapped one level into a (checked)javax.script.ScriptException
ScriptingContainer
continues to use the embed exception wrapping by default, but there's a way to disable wrapping using the added constructorjava.lang.Exception
types will be wrapped - neverjava.lang.Error
regardless of whether it's coming from a Ruby raise (no way to detect)Potential Open Questions:do we want to keeporg.jruby.embed.InvokeFailedException
deprecated given ScriptingContainer will still wrap into those by defaultmaybe a betterScripingContainer
API is needed e.g. factory methods where we always turn off wrapping by default (esp. if we keepInvokeFailedException
deprecated)