[ji] support java.lang.Throwable#backtrace_locations#9461
Conversation
9e515d7 to
129df00
Compare
129df00 to
de37a96
Compare
|
Based on Rails usage, as mentioned in #9458 would likely make sense to re-target this to 10.0.x |
headius
left a comment
There was a problem hiding this comment.
Minor suggestions to clean it up a bit but generally looks fine. In the future we might want to also use our JRuby-aware stack trace processing to rewrite JIT and interpreter frames but that's out of scope here.
| } | ||
|
|
||
| @JRubyMethod | ||
| public static IRubyObject backtrace_locations(final ThreadContext context, final IRubyObject self) { |
There was a problem hiding this comment.
This and backtrace are very similar. Maybe share the common parts and just construct the elements differently.
There was a problem hiding this comment.
yeah the preamble, but even if we dry out the loop mapping with a function you still need to return a different array.
| IRubyObject[] ary = new IRubyObject[length]; | ||
| for ( int i = 0; i < length; i++ ) { | ||
| ary[i] = newLocation(runtime, elements[i + offset]); | ||
| ary[i] = new Location(runtime, locationClass, elements[i + offset]); |
There was a problem hiding this comment.
Would a new overload of newLocation make sense here?
There was a problem hiding this comment.
not sure, literally would be the same as doing new Location() directly.
de37a96 to
e64e131
Compare
(cherry-picked from commit 6d7819e) Signed-off-by: Chad Wilson <29788154+chadlwilson@users.noreply.github.com>
(cherry-picked from commit 6d7819e) Signed-off-by: Chad Wilson <29788154+chadlwilson@users.noreply.github.com>
(cherry-picked from commit 6d7819e) Signed-off-by: Chad Wilson <29788154+chadlwilson@users.noreply.github.com>
…e-locations [9.4] backport [ji] support java.lang.Throwable#backtrace_locations (#9461)
the one thing left, in terms of Ruby exception compatibility, would be
Exception#exception(str)which might be a bit tricky to fully support.