Functional Programming中處理Exception的方法

-

前言

以前剛從Java轉換到其他語言時有個困擾，就是Checked Exception(受檢例外)不見了。這會導致呼叫function的時候，難以判斷程式到底會不會丟出Exception。

其實關於Checked Exception的討論在網路上已經很多了，我google了兩篇覺得寫得還不錯的，覺得應該存在的正方[1]，覺得不應該存在的反方[2]，講起來其實都有些道理。

我自己比較偏向Checked Exception必須存在，但更準確來說是「我自己的checked exception應該要存在」。在設計自己的function時，若出現需要raise exception的情況，必定是我覺得這個東西要知會上層中斷流程，並做出一定的處理。而這應該存在於function的interface當中，不該讓同事看了文件或看了原始碼才發現要處理例外。

至於其他library的程式碼，我是覺得隨意。一方面大多數library並不會隨便丟出錯誤。另一方面就算他丟出錯誤，很大部分也是無法處理的錯誤，就讓他直接丟到頂端被top level的try catch給接住也無妨。

嘗試: 回歸錯誤碼檢查

既然想讓exception在function的介面上展現，最簡單的一個方法就是用class給包裝起來。(下面用dart程式碼呈現)

class Result{
  Result(this.result);
  Result.error(this.error);

  int result;
  Exception error;
}

先宣告一個class，裡面有正常的回傳值，也有異常的回傳值。
若程式正常執行則使用預設的constructor，出現錯誤則用error的constructor。如下

Result func(){
  return Result(0);
  // return Result(Exception("Error!!!"));
}

void main(){
  Result v = func();
  if(v.error != null){
    // 處理錯誤
    return;
  }
}

在程式的執行流程中，如果出現error != null的狀況，就進行處理。若有需要也可以再將exception向上傳遞。

這邊為了易懂省掉了generic type的設定，實務上為了更一般化一定要用上generic type來包裝。

缺點

缺點也是顯而易見，exception受歡迎的原因就是因為它可以中斷程式流程，並把錯誤集中處理。若按照這種寫法，很快的程式中就會開始充斥著類似下方的程式碼。

void main(){
  Result a = func1();
  if (a.error != null){
    // 處理
  }
  Result b = func2();
  if (b.error != null){
    // 處理
  }
  Result c = func3();
  if(c.error != null){
    // 處理
  }
}

所有錯誤處理分散在function的各個地方，程式流程也變得非常不線性，看一段錯誤處理又要看一段正常流程，相信許多人會因此感到痛苦。

Functional Programming下的處理方法

型態修改

在正式介紹FP的處理法之前，先把上面的型態宣告做點小修改。

class Result{}

class ResultFailed extends Result {
  ResultFailed(this.e);
  Exception e;
}

class ResultSuccess extends Result { 
  ResultSuccess(this.value);
  int value; 
}

可以想見，一個Exception跟一個正常值，根本不會是同一種type，所以用一個Result來裝兩者，在語意上其實是有點問題的。
此處先將Result作為Base Class，並另外分出兩種class來記錄正確和錯誤。

串接寫法

剛剛程式中最大的問題出在無法將錯誤集中處理，現在試著幫Result加上一個function來解決這個問題。

// Transform是一個parameter為int，return type為int的function。
typedef Transform = int Function(int value);
class Result{
  Result map(Transform fn){
    if (this is ResultException){
      return this;
    }else if (this is ResultSuccess){
      return ResultSuccess(fn(a));
    }
  }
}

Result func(){
  return ResultSuccess(0);
  // return ResultFailed(Exception("NOOO"));
}
void main(){
  Result value = func()
    .map((int v) => v+10)
    .map((int v) => v+10)
    .map((int v) => v+10);

  if (value is ResultFailed){
    // 處理錯誤
  }
}

先集中精力看main function的部分，分析一下map造成了什麼效果？

在執行func獲得一個Result之後，會想拿這個Result去做去執行其他運算，例如說+10。但是在此處我們把「從Result class中提取int值」的動作交給了map，map再去呼叫使用者所傳入的function。

這有什麼好處？

回頭看看map的實作，會發現map除了在程式正確執行的時候，幫助unwrap int值，也能在程式錯誤的時候，選擇性的不執行傳進來的function。因此可以百分之百肯定，當執行function時，參數v鐵定是有值，且沒有exception存在。

要再functional一點的話，應該在Result上再外加一個handleError的function。

因此我們可以這樣描述main的執行

  1. 如果func()執行成功，沒有丟出exception，那麼每一個map都會被執行，最終會得到一個ResultSuccess(30)的結果。
  2. 如果func()執行失敗，丟出了Exception(“NOOO”)，那麼接下來的每一步運算都不會被執行。最後的結果還是Exception(“NOOO”)。

而在這樣的寫法中，正確的計算步驟被層層串接，錯誤的處理則被推遲到最後才執行。就跟try catch想達到的效果是一樣的。

另外一方面，如果不想在當前的function處理錯誤，就可以將function的return type換成Result，這樣所有使用此function的人，都會強制注意到此function是有可能回傳Exception的，進而選擇執行錯誤處理，或是將Exception再遞交給更上一層。這跟Java中Checked Exception想達成的效果也是一樣的。

已經存在的輪子

作為一個簡化的例子，這個Result class其實有很多缺陷。不過幸好在FP的世界裡這樣的設計已經有自己的名稱，叫做Either，且很多程式語言都已經有實作，所以實務上並不需要自己重刻一次這樣的工具。

這裡貼幾個Either的實作

Either的繼承樹長得像這樣。

class Either<L,R> {}
class Left<L,R> extends Either<L,R>{}
class Right<L,R> extends Either<L,R>{}

Either的設計其實更為一般化，並沒有規定Left和Right必須要是一個Exception和一個正確值。但在使用慣例上，Left是作為Exception存在，Right作為正確值存在。最好是跟隨這個慣例，並避免將Either用在非Exception處理的地方。

Reference

  1. 王垠: Kotlin 和 Checked Exception
  2. 浅谈Kotlin的Checked Exception机制

留言

張貼留言

這個網誌中的熱門文章

LiteDb簡單key-value pair存法

-
LiteDb 是C#上簡單的NoSql資料庫，不過想用一個collection來存不同型別的key-value pair就略顯麻煩。 好在LiteDb本身有提供schema-less的用法，詳細可參閱 Collections - LiteDB :: A .NET embedded NoSQL database 。 再略微調整一下，就可以撰寫一個通用的key-value pair存法。 Base class如下 public class KeyValueRepository { public KeyValueRepository ( ILiteCollection < BsonDocument > collection ) { _collection = collection ; } private ILiteCollection < BsonDocument > _collection ; protected void SetValue ( string key , object ? value ) { _collection . Upsert ( new BsonDocument { [ "_id" ] = key , [ "Value" ] = BsonMapper . Global . Serialize ( value ) } ) ; } protected T ? GetValue < T > ( string key ) { return BsonMapper . Global . Deserialize < T > ( _collection . FindById ( key ) ? [ "Value" ] ) ; } } 繼承後，要宣告不同的type就比較方便了。 public class MyRepository : KeyValueRepository { public MyRepository...
閱讀完整內容

解決WSL在Windows檔案系統下速度緩慢的問題

-
圖片
背景 微軟在 比較 WSL 1 和 WSL 2 | Microsoft Docs 這篇文章有提到，WSL 2在存取windows檔案系統時速度會變慢。雖然 cd / ls 這類指令無法察覺，但一旦使用到git，大量的檔案存取立刻讓效能有感變慢。有些用戶甚至還沒開始使用git指令，只是進入git repository，就足以讓接下來的每個指令延遲一秒以上。 分析原因 使用git會變慢的理由應該不用多談了，那為何單單只是進入git repository，速度就會有感下滑呢？這是因為很多的shell theme(bash/zsh)，為了美觀和實用，都有附加「進入git repository時，提示目前branch」的功能。 而這也導致了在git repository底下時，無論輸入任何指令，shell皆會在每個指令間使用git指令，間接拖垮執行速度。 解決方法 思路 其中一個方案是回去用WSL 1，這也是微軟的推薦方法。 第二種方案則是改為使用windows的git，本篇主要會介紹這個方法。 首先要知道，任何windows的工具皆可在WSL中直接呼叫(前提是工具有在環境變數當中)。以git為例，若在Windows安裝過git，只要在WSL中輸入 git.exe ，即可使用Windows的git。 $ which git.exe /mnt/c/Program Files/Git/cmd/git.exe 因此只要利用這個特性，在WSL進入Windows檔案系統時，將原先的linux git替換為windows git，就不會再感到延遲了。 oh-my-zsh的解決方案 這裡提供oh-my-zsh的解決方案。 對原始碼有興趣的可以看看oh-my-zsh針對git所做的擴展， 連結 。 oh-my-zsh主要使用 __git_prompt_git 此function來執行git操作。因此我們只要遮蔽此function，將git更改為windows版本，即可解決進入git repository時速度緩慢的問題。 當然，指令上的git也必須進行簡單替換，最後結果如下。 function __git_prompt_git ( ) { GIT_OPTIONAL_LOCKS = 0 command git.exe " $@ ...
閱讀完整內容