0

カスタムJVMの動作は少し異なる可能性があることを知っており、観察された動作が実際のJVMと同じであるかどうかを確認しようとしています。また、私はこのようなものを一貫して機能させる方法を探しています。

私が見た中で最悪の部分は、例外がJVMによって完全に食べられていることです。例えば：

public myMethod(String test) extends Remote {
    if(test.equals("Hey"))
        doSomething()
}

「test」にnullを渡すことに対するコード内の2つの応答を見てきました。1つは、「NullPointerException」をログに記録することです。他には何もありません、その文字列だけです。

もう1つは、何もログに記録されないことです。コードの実行は停止するだけで、このコードが実行された後は何も実行されません（呼び出し元のメソッドの周りにtry / catchがある場合でも）

また、例外の後、呼び出しスレッドは継続しないようです（このようなバグを追跡するのは驚くほど困難です）。

このメソッドの周りにtry/catchをスローしてエラーをログに記録すると、正常に機能します。

確かに、私はカスタムコードを使用して古いJVMに取り組んでいるので、あまり助けは期待していませんが、誰かがこのような動作を見たことがありますか？たぶん古いJVMで？例外をネットワーク経由でスローすることになっていますか、それともリモートシステムにスタックトレースを出力することになっていますか？

例外をRemoteExceptionでラップし、それを再スローすることは合理的な解決策ですか？

助言がありますか？（新しいJVMの仕様は別として、これは可能性の領域からはほど遠いため、面白くありません）

4

1 に答える 1

0

これは、再現可能な動作になりました。スローされた例外は、アクセスできない中間レイヤーでキャッチ/再スローされていませんでした。コードを呼び出すスレッドが例外を飲み込んでいました。

VMの問題ではありませんでした。

これを入れるだけで答えを受け入れることができます。

于 2010-06-18T18:51:10.443 に答える