Question

在我的GWT项目中，我为服务调用中抛出的异常链创建了一个精心设计，但却发现getCause()始终在客户端的null方法中返回onFailure()

通过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序列化为我的异常类做出异常？

Answer 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，因此，在客户端捕获的序列化必须与GWT兼容JRE类的Javascript实现。查看GWT JRE Emulation Reference了解更多信息。

（请注意，他们可能试图在客户端实施Throwable子类更积极，但即使他们这样做，他们仍然无法确保，例如，某些第三方库的例外将是现在，这会破坏客户端的反序列化。）

我的项目中也有一个相当精细的异常链。我所做的是确保在所有异常对象构造函数中保留消息而不是原因。不幸的是，我们说，对于他们的消息而言，一些Java异常不是冗长，而是与C＃相反。例如，NullPointerException具有完全空的消息，而ArrayIndexOutOfBoundsException只有一个数字。所以，我注意在我的构造函数中将消息的名称嵌入到消息中。

它并不完美，但它确实有效。

为什么不GET序列化异常原因链？

1 个答案: