差異處

這裏顯示兩個版本的差異處。

連向這個比對檢視

Both sides previous revision 前次修改
下次修改
前次修改
java:effective_java:exceptions:strive_for_failure_atomicity [2022/03/23 23:35]
tony [Introduction]
java:effective_java:exceptions:strive_for_failure_atomicity [2023/06/25 09:48] (目前版本)
行 2: 行 2:
 ====== Effective Java - Strive for failure atomicity ====== ====== Effective Java - Strive for failure atomicity ======
 ===== Introduction ===== ===== Introduction =====
-這個Item主要在宣導「在工作失敗時,要努力讓物件的狀態完好如呼叫前」。+這個Item主要在宣導「在工作失敗時,要努力讓物件的狀態完好如呼叫前」。如果method滿足這個條件,就可以稱為具有failure-atomic的method。(Note.要考慮的不只有待操作的物件,應還有做為輸入參數的物件)\\ 
 +\\ 
 +第一個方法是操作Immutable object。因為它不會被改變,自然而然就滿足所謂的failure-atomic。依照過往經驗,如果要回傳一個Collection,盡量讓它是Immutable object只用於計算,並避免直接的修改造成side effect。\\ 
 +\\ 
 +第二個方法就是在造成物件狀態改變之前,做precheck。假如不做檢查讓物件進入了錯誤的狀態,反而可能會衍生更多問題,且不好debug。\\ 
 +\\ 
 +第三個方法就是先把物件複製一份在操作。就算發生問題,也不會影響到原本的物件狀態。\\ 
 +\\ 
 +最後一個方法,就是要實做一段recovery code,好讓發生問題時,可以rollback回原本的狀態。像是使用資料庫的Transaction,或操作檔案前先複製一份,有問題在還原檔案等等。\\ 
 +\\ 
 +使用這些方法,都要注意一下"​代價"​與"​多執行緒存取"​的問題。像要複製物件或準備環原點,都會存在著性能開銷,且程式碼往往會複雜一些些;比較低成本的Immutable object不一定適用於各種情況;precheck則大部分情況都有可能要注意多執行緒的存取,假如是依賴目標物件的狀態做precheck的話。\\ 
 +\\ 
 +另外,書中有建議,如果無法滿足failure-atomic的method,"​建議"​要寫註解讓用的人知道。 
 ===== Note ===== ===== Note =====
 Effective Java第三版Item 76。 Effective Java第三版Item 76。