爲什麼GWT不會序列化異常的原因鏈？

在我的GWT項目中，我創建了一個精心設計的異常鏈，以便在服務調用中拋出異常，但發現getCause()總是在客戶端的onFailure()方法中返回null。爲什麼GWT不會序列化異常的原因鏈？

通過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序列化爲我的異常類做一個例外？

來源

2012-09-16 Saintali

請注意代碼中的註釋，說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的Javascript實現兼容JRE類。查看GWT JRE Emulation Reference瞭解更多信息。（請注意，他們可能試圖在客戶端實現Throwable子類時更積極，但即使他們這樣做了，他們仍然無法確保某些第三方庫的例外會這會破壞客戶端的反序列化。）

我也有一個相當詳盡的異常鏈，在我的項目中。我所做的是確保在所有異常對象構造函數中保留消息，而不是原因。不幸的是，我們應該說，一些Java異常對於它們的消息來說不是冗長的，而與C＃相反。例如，NullPointerException有一個完全空的消息，而ArrayIndexOutOfBoundsException只有一個數字。所以，我小心地將消息中的原因異常的名稱嵌入到我的構造函數中。

這並不完美，但它的工作原理。

來源

2012-09-16 15:28:39

這不會破壞客戶端代碼，我會說。因爲'Throwable'子類的聲明域已經被序列化了，所以只有在GWT忽略的'Throwable'本身聲明的域。 – Saintali

爲什麼GWT不會序列化異常的原因鏈？

回答

相關問題