程式人時常要與錯誤搏鬥,然而介紹或探討錯誤處理的文件或書籍,相對來說還是少了許多。

由於許多語言都內建了例外(Exception)處理機制,目前大家對以例外機制來處理錯誤的方式較為熟悉,然而觀察其他語言典範,從中看到一些錯誤處理的方法,以不同的習慣來思索,因此在錯誤處理上,可獲得不少的啟發。

舉例來說,例外處理多半是命令式風格,想想看函數式的世界中,會是怎麼處理例外呢?

解決null問題的Option
Scala中有個Option,guava-libraries中有個Optional,JDK8中也將有個Optional類別,它們的存在目的,基本上是為了避免使用null,以免遭受因為使用了null,而造成的各種問題。我曾經在專欄〈補救null的策略〉中談過,null的問題在於語義含糊不清,可以實現速錯(Fail fast)概念,或者是建立有明確語義的型態來取代null。

實際上,Option的概念來自於函數式。以Haskell為例,它沒有null的概念,最類似的值是Nothing,它是Maybe型態,Maybe的其他值要由Just構造。

在Haskell中,如果函式執行後也許會產生某型態結果,或者是沒有結果,那就會傳回Maybe型態的值,呼叫函式的客戶端可使用模式比對(Pattern match)在傳回Just時取得其中的值,在Nothing時,作沒有結果時的處理。

Scala中的Option有兩個子類別Some與None,對照來說,Option相當於Haskell的Maybe,Some對應於Just,None對應於Nothing,Scala支援函數式設計,Some與None定義為案例類別(Case class),以支援模式比對。

觀察Haskell的Maybe或是Scala的Option的使用時機,你會發現它們多半用在計算可能失敗而沒有結果的場合,也就是說,Maybe或Option常是函數式世界中處理計算失敗或錯誤的方式。

現在不少命令式語言都逐漸納入函數式風格,除了一級函式是最顯而易見的函數式特性之外,實際上guava-libraies中納入Optional的概念也是,只不過在不支援模式比對的Java語言中,會使用Optional的isPresent方法來確認是否有包裹值,也就是說,Optional除了避免null相關問題外,實際上也給了我們一些以函數式風格處理錯誤的機會。

分別表現對錯資訊的Either

在命令式語言逐步結合函數式概念的過程中,常會出現一些讓熟悉命令式風格的程式人困惑的一些元素。

以嘗試融合物件導向及函數式兩種典範的Scala為例,除了Option之外,還提供了Either型態。

表面上看來,在函式可能產生兩種型態之一計算結果時,可以令其傳回Either,實際上Either多半運用於處理錯誤,它有Right與Left兩個子類別,前者是計算成功時用來包裹正確結果(Right的英文暗示著正確),後者是在計算失敗時,用來包括為何計算錯誤的有效訊息。

Haskell中也有個Either型態,分別可使用Right與Left兩個值建構式(Value constructor)。同樣地,函數式的Haskell或Scala中,Either的值都可以進行模式匹配。

從Java這類命令式語言中看Either,容易有的疑問是「為什麼不直接拋出例外」?拋出例外,意謂著客戶端若要處理例外,必須使用try-catch語法,這語法容易寫出更動變數值的程式流程,而拋出例外本身就代表著會中斷程式流程,也就是函數有可能不會有傳回值,這不符合函數式風格。Option的存在解決了部份問題,然而Option在計算失敗時只傳回None,如此一來只會知道計算失敗,但不會知道失敗的原因。

我們可以使用Either,來解決這類問題。以Scala為例,在結合例外型態下,假設計算成功會傳回Int,計算失敗會以Exception包裏錯誤訊息,那麼函式傳回值可以是Either[Exception, Int],假設現在計算成功得到93,則傳回Right(93),否則建立例外物件e並傳回Left(e),如此一來,呼叫函式的客戶端可以模式匹配作相對應的處理,即使客戶端不打算處理例外,也不用撰寫try-catch,程式依然可以進行,也就是可以延遲例外的處理。

有了Either這類型態,錯誤處理的方式就可以有函數式的可能性,也因此支援Java進行函數式風格撰寫的Functional Java程式庫,亦定義了Either這個型態。

看看Scala 2.10新增的Try
在Scala中有趣的一點是,try-catch語法是運算式(Expression),也就是try-catch會有傳回值,這使得在運用try-catch語法的場合中,依舊可符合函數式風格。

因此,若察看Either的API文件時,可以看到以下的範例程式碼:

val result: Either[String,Int] =
try { Right(in.toInt) }
catch { case e: Exception => Left(in) }

實際上這是個很常見的模式,因此在Scala 2.10中增加了Try類別,可以直接將上例撰寫為val result: Try[Int] = Try(in.toInt),如果in.toInt執行成功,會傳回Success實例包裏結果,若失敗則以Failure實例包裏例外物件。呼叫函式的客戶端,同樣可進一步地進行模式匹配。

Try型態的主要作用之一,在於提供比Either更明確的語意,Try的兩個子類因而明確地命名為Success與Failure;Try的另一作用是封裝共用的try-catch處理流程。

而在Java領域,談到封裝try-catch共用處理流程的實際例子,是Spring的JdbcTemplate。它封裝了使用JDBC API時繁瑣的try-catch處理流程,這不單是為了重用流程樣版,也是為了可讀性,在《Clean Code》書中有個小節談到了〈提取Try/Catch區塊〉,也是類似的道理。

既然知道了Try的作用,是在提供更明確語意與重用try-catch流程,因此,要在Java中建立類似的型態,基本上就不是問題,雖然try-catch在Java中不是運算式,但可以封裝在函式中,並以return來作到類似功能。

然而,現階段的Java版本不支援Lambda語法,寫來會比較囉嗦,如果在JDK8中,則可以較簡潔地寫為tryIt(() -> Integer.parseInt(input)),並令tryIt傳回Try實例來達到類似功能。

從多種典範中學習並思考

在過去,程式人習慣使用null,後續因為層出不窮的錯誤,以及《Null References: The Billion Dollar Mistake》之類的呼籲,有人開始思考如何不使用null,因而引入了函數式領域的概念,使用了Option來讓語意明確,現在不少程式人都知道Option的概念,與使用的時機。

隨著命令式語言漸次地引入函數式的元素,程式人也得瞭解更多的函數式概念,方能瞭解這些元素實際的使用時機。

就像Either,它不僅僅是用來包裹可能的兩種型態傳回值,否則的話,基本上,Map或其他自訂型態也作得到這點。Either讓編譯器有機會進行型態檢查,更重要的是,它常應用在錯誤處理的場合。

因此,程式語言融合多種典範,代表著程式人需要更多的思考方向,就如Option、Either、Try等元素若進入到命令式語言之中,程式人在必要的時候,就得改變一下處理錯誤的習慣,嘗試從另一角度來解決問題。

作者簡介


Advertisement

更多 iThome相關內容