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