有人研究過,程式中可能會有高達90%的比率在管理與處理錯誤,Bob大叔在《Clean Code》中談到:「許多程式碼完全由錯誤處理所主宰」,90%的比率,是真的在管理與處理錯誤的邏輯嗎?還是只是如Bob大叔說的,根本就是散亂的錯誤處理程式碼?

商務邏輯相關的程式碼需要重構,對於錯誤處理程式碼的重構,我們也有許多需要學習的地方。

錯誤處理就是一件事

在重構或程式碼可讀性的概念中,有個共同特性,就是函式(方法)應該只做一件事,避免函式中的程式碼陷入邏輯泥塊(Logical clump)。在沒有例外處理的語言中,透過回傳錯誤碼,讓函式客戶端可以檢查執行結果,確認後續是要進行正常或錯誤處理流程,如果客戶端必須呼叫多個函式來完成一項任務,在檢查錯誤碼、正常與多個錯誤處理流程夾雜的情況下,容易使客戶端程式碼變得混亂。

例外處理機制可以在錯誤發生的時候拋出例外,讓錯誤處理能推到想要的邊界進行處理。以Java來說,客戶端可以在try區塊中處理正常流程,在catch區塊處理呼叫各函式時可能拋出的例外,讓原先糾纏在錯誤處理流程中的正常流程清楚地呈現出來,try區塊中的流程亦可抽取為函式,獨立地做一件事,那麼,目前的try-catch就能專心地做錯誤處理這件事,如同Bob大叔說的:「函式應該只做一件事,而錯誤處理就是一件事」。

有時,例外處理流程會形成一種模式,例如涉及資源建立、使用與關閉的操作,若會拋出例外,為了有限資源在各種錯誤發生時,都能確實釋放,不免要撰寫類似的try-catch-finally流程,在具有受檢例外的Java中,更是難以避免這類情況,像是JDBC的處理流程就是如此,此時,可以採用樣板回呼(Template callback)模式,適當地讓資源相關操作從錯誤處理流程中獨立出來,而Spring的JdbcTemplate就是這類實現。

因為這類資源建立、關閉的操作模式太頻繁出現,JDK7就提出了try-with-resources語法來解決這類需求,確實地讓資源建立、使用與關閉的操作與錯誤處理分離,若進一步地結合JDK8的Lambda語法,還可讓資源的使用從建立與關閉中分離。

例如,設計一個open方法的時候,就可以專心在FileInputStream的使用,讓開啟檔案的意圖更為顯而易見:

open(fileName, fileInputStream -> {
    // 操作FileInputStream實例
});

多個捕捉做相同處理時的重構

如果多種例外捕捉後,做的都是相同的錯誤處理,像是日誌,或者是將程式庫的例外封裝為自定義例外等,錯誤處理的程式碼必然就出現重複,自然就會呈現需要重構的訊號。因為多種例外做的都是相同的事,可將有繼承關係的例外處理程式碼,合併在父類別的捕捉區塊中,但不建議使用catch-all的方式,例如使用Exception或Throwable來捕捉所有例外,因為對於其他不相關的例外,這是一種隱藏錯誤的做法。

然而,在合併有繼承關係的例外處理程式碼之後,仍會發現沒有繼承關係的例外處理程式碼出現重複,此時,Bob大叔在《Clean Code》中提出的作法是包裹呼叫的API,確保它在捕捉各種例外後,能轉換為(自定義的)共同例外型態,如此客戶端就只需要捕捉一種例外,因而可讓客戶端程式碼大幅簡化,如果使用的是第三方API,也可以同時降低了對它的依賴。

如果多種例外在捕捉之後,做完相同處理就將原例外重新拋出,可以參考guava-libraries的作法,你可以使用catch-all的方式捕捉各種型態的例外,做完相同錯誤處理之後,使用Throwables.propagateIfInstanceOf以指定的例外型態重新拋出(通常是受檢例外),或者是使用Throwables.propagate,將原例外以RuntimeException包裹後重新拋出,既消除了重複的錯誤處理程式碼,又避免了隱藏錯誤。

雖然,實際上,Throwables.propagateIfInstanceOf只是將型態判斷與轉型的邏輯封裝並予以重用,但對客戶端程式碼的簡化確實有所幫助,不過,這種方式對於錯誤處理時進行例外型態轉換,或者是不重新拋出的情況並不適用,guava-libraries的〈ThrowablesExplained〉文中,也解釋了其他一些不適用的場合。

而在JDK7中,對於多個捕捉做同一件事的情況,提出了Multi-catch語法,算是為這問題,提出了較好的解決方案。

以多個捕捉,做不同處理時的重構

如果多種例外捕捉後,分別進行不同的錯誤處理,此時得檢視多種例外是由單一方法拋出,或多個方法操作而分別拋出不同例外。

最常見的情況是,一個try區塊進行了數個會拋出例外的操作,然後底下連續多個catch區塊,逐一針對不同例外作處理。實際上每個會拋出例外的方法發生錯誤時,理由應該是各不相同的,應試著讓這些方法各有一個try-catch區塊,讓每個方法的錯誤處理流程各自顯露出來。

一旦你根據不同方法引發的例外,將一個try搭配多個catch的程式碼,分解為數個try-catch區塊之後,應當立即想到:「錯誤處理就是一件事」,而兩個以上的try-catch時,無論那些try-catch是形成巢狀,或者是瀑布式流程,都意謂著你的程式碼做了兩件以上的事,而重構的方式之一,就是每個try-catch重構至獨立的方法之中,讓每個方法都只會出一個try陳述。

當發現一個方法中會出現多個try-catch時,而每個try-catch都做類似模式(但細節不同)的轉換或錯誤處理時,如果你接觸過函數式的錯誤處理風格,例如我先前專欄〈函數式風格錯誤處理〉中談過的Option、Either、Try等概念,就有可能進行Monad風格的錯誤處理。

我在專欄〈神秘的Monad不神秘〉中,曾談到Optional的flatMap可連續處理null與物件值轉換的問題,實際上,Mario Fusco在〈Monadic Java〉中就以類似風格,設計了Validation等類別,可以用Monad風格對使用者,進行如下的程式碼驗證與驗證失敗訊息之收集,而又不會迷失在瀑布式的ValidationException捕捉程式碼之中:

Validation<List<String>, Person> validation = success(person).failList()
    .flatMap(Validator::validAge)
    .flatMap(Validator::validName);

重構是看待錯誤處理的一個角度

既然程式中可能會有高達90%的比率在管理與處理錯誤,我們真的該認真且從不同角度去看待,像是受檢或非受檢例外的運用、例外應捕捉或拋出、避免隱藏錯誤、換個典範風格思考錯誤處理的可能性等,都該有所思考,我在先前寫的專欄文章〈Shit Happens!該抓還是該丟?〉、〈避免隱藏錯誤的防禦性設計〉與〈函數式風格錯誤處理〉,都曾做過一些探討。

從重構角度出發,來看待錯誤處理程式碼,你會發現,Martin Fowler的《Refactoring》中揭露的重構原則,對待錯誤處理程式碼也是適用的。因為,錯誤處理之所以重要,就在於它是處理不對的事情,本身必須正確。

然而,就如Bob大叔說的:「如果它糢糊了原本程式碼的邏輯,那就不對了。」

作者簡介


Advertisement

更多 iThome相關內容