在我的 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 序列化为我的异常类创建一个异常?
最佳答案
请注意代码中的注释:更改我们为 Throwable 序列化的字段集将需要更改我们的 JRE 仿真版本的 Throwable。
这就是代码存在的原因,因为 Throwable 是Java,而不是 Javascript,因此,在客户端捕获的任何被序列化的内容都必须与 GWT 的 JRE 类的 Javascript 实现兼容。查找GWT JRE Emulation Reference了解更多信息。
(请注意,他们可能会尝试更积极地在客户端实现 Throwable 子类,但即使他们这样做了,他们仍然无法确保某些第三方库的异常是现在,这会破坏客户端反序列化。)
在我的项目中,我也有一个相当复杂的异常链。我所做的是确保在我所有的异常对象构造函数中保留消息,而不是原因。不幸的是,我们应该说,某些 Java 异常在其消息方面不够冗长,例如与 C# 不同。例如,NullPointerException 有一个完全空的消息,而 ArrayIndexOutOfBoundsException 只有一个数字。因此,我小心地将导致异常的名称嵌入到我的构造函数中的消息中。
它并不完美,但它确实有效。
关于java - 为什么 GWT 不序列化异常的原因链?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/12448061/