有没有办法在jruby中获得合理的堆栈跟踪？

Question

当我的jruby程序出乎意料地抬起并给我一个堆栈跟踪时，这几乎是不可理解的。它显然是来自内部解释器的东西，并且让我很难弄清楚我的实际程序的实际调用堆栈是什么。

类似的事情（仅限摘录）：

    from CachingCallSite.java:326:in `cacheAndCall'
    from CachingCallSite.java:170:in `call'
    from CallOneArgNode.java:57:in `interpret'
    from LocalAsgnNode.java:123:in `interpret'
    from NewlineNode.java:105:in `interpret'
    from BlockNode.java:71:in `interpret'
    from RescueNode.java:222:in `executeBody'
    from RescueNode.java:117:in `interpret'
    from EnsureNode.java:96:in `interpret'
    from ASTInterpreter.java:74:in `INTERPRET_METHOD'
    from InterpretedMethod.java:161:in `call'
    from DefaultMethod.java:178:in `call'
    from CachingCallSite.java:316:in `cacheAndCall'

并不仅仅是这些从我的实际程序中穿插了调用堆栈行 - 我的实际程序的调用堆栈似乎根本没有出现在堆栈跟踪中。使它不那么有用，它的目的是帮助我找出实际引起异常的内容。

我想我记得在过去的某个时候弄清楚一些命令行参数来给jruby，与调试或JIT或其他东西相关，这将导致一个合理的合理堆栈跟踪（可能以JIT性能为代价或什么东西？）。

但是试图再次找到这个，我没有运气，花了很多时间试图找到jruby docs，谷歌搜索等等，没有运气找到任何导致合理堆栈跟踪的命令行args。

有人知道吗？

Answer 1

我经常force compilation使用jruby.compile.mode=FORCE代码，因为编译后的代码将在堆栈跟踪中包含Ruby名称和行号。这会让事情变得更慢，所以我不会一直保持这种状态。

As of JRuby 1.7.10，尝试将jruby.rewrite.java.trace设置为true。

修改

从同一个Twitter讨论中，另一个想法是使用

rescue NativeException
  raise
end

哪个也有帮助。当然，您必须知道异常发生的位置，但它应该有所帮助。