2

私の GWT プロジェクトでは、例外チェーンがサービス呼び出しでスローされるように精巧な設計を作成しましたが、クライアントのメソッドでgetCause()常に返されることがわかりました。nullonFailure()

GWT シリアライゼーション コードでデバッグした後、次のコードを見つけましたSerializabilityUtil。

private static boolean fieldQualifiesForSerialization(Field field) {
    if (Throwable.class == field.getDeclaringClass()) {
        /**
         * Only serialize Throwable's detailMessage field; all others are ignored.
         *
         * NOTE: Changing the set of fields that we serialize for Throwable will
         * necessitate a change to our JRE emulation's version of Throwable.
         */
        if ("detailMessage".equals(field.getName())) {
            assert (isNotStaticTransientOrFinal(field));
            return true;
        } else {
            return false;
        }
    } else {
        return isNotStaticTransientOrFinal(field);
    }
}

誰でもここで私を助けることができます.なぜGWT設計者はこれをコードに入れるのですか? に本当に問題がある（またはセキュリティに敏感な）ものはありThrowable.causeますか？

当然のことですが、GWT シリアライゼーションに例外クラスの例外を作成するように指示するにはどうすればよいでしょうか?

4

1 に答える 1

1

コード内のコメントに注意してください。Changing the set of fields that we serialize for Throwable will necessitate a change to our JRE emulation's version of Throwable.コードがそこにある理由は、Throwable は Java であり、Javascript ではないためです。そのため、クライアント エンドでキャッチされるようにシリアル化されるものはすべて、JRE クラスの GWT の Javascript 実装と互換性がある必要があります。詳細については、 GWT JRE エミュレーション リファレンスを参照してください。

(クライアント側で Throwable サブクラスを実装することでより積極的にしようとした可能性があることに注意してください。これにより、クライアント側のデシリアライゼーションが中断されます。)

私のプロジェクトにも、かなり精巧な例外チェーンがあります。私がしたことは、すべての例外オブジェクト コンストラクターで、原因ではなくメッセージを保持するようにしました。残念ながら、一部の Java 例外は、たとえば C# とは対照的に、そのメッセージに関しては冗長ではありません。たとえば、NullPointerException にはまったく空のメッセージがありますが、ArrayIndexOutOfBoundsException には数字しかありません。そのため、コンストラクターのメッセージに原因例外の名前を埋め込むように注意しました。

完璧ではありませんが、機能します。

于 2012-09-16T15:28:39.453 に答える