Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Improve two-way integration of Java and Ruby exceptions #4781
For #4699, we removed the automatic initCause call for Java exceptions raised from Ruby. There were a few issues with that logic:
In light of these problems, I think we should not reinstate automatic cause-setting for Java exceptions, but we do need a way to provide a cause. There's a few ways this might be done...I try to describe some below.
RubyException could hold a reference to its "container" RaiseException, so it can be re-raised without making a new one.
When providing the Java cause, this exception could be used, either through a new JRuby-specific method:
ex.throwable # or ex.to_java(Throwable)
...or via some magic trickery during value conversion in JI, when we see a RubyException is being passed for a Throwable.
We have also discussed in the past building a parallel exception hierarchy for RaiseException. In this structure, all exception types that currently exist would still work, but for each Ruby exception there would be an equivalent Java exception of the same name. The two would be inseparable, like the proxy objects we use for JI. This would allow the Ruby exception to behave more naturally as a Java exception, and allow Java code to rescue Ruby exceptions by name (rather than the RaiseException dance we have today).
All this combined would improve our integration between Ruby and Java exceptions.
changed the title
Provide a way to initCause for a Java exception with a Ruby exception
Sep 6, 2017
referenced this issue
Feb 27, 2018
I have abandoned the old branch and have a new (working) branch in exceptions2.
The logic here works like this:
At the moment this does not introduce any new Throwable types to the system. I need to work on cleaning up initialization, especially wrt backtraces.
Ok, without any additional modification, we can now do the following to attach a Ruby exception as the cause for a Java exception:
We'd need to set up all Exception classes to report Throwable as their "native" Java class, but I think that's all. They'd be eligible for passing to methods that take Throwable, and the toJava logic I added will retrieve the same throwable every time.