漂亮的with，魚與熊掌可以兼得
假設要加載磁盤上的一個文件，并以二進制形式讀取文件的數據。若要從健壯性的角度考慮，需得考慮兩種異常情況：
- 加載文件失敗，例如給定的文件路徑并不存在該文件
- 讀取文件數據失敗，例如磁盤扇區有故障
顯然，生活中總是存在著例外，我們不能樂觀對待，還得未雨綢繆，唯有對這些異常情況做充分判斷，由代碼組成的軟件系統才夠健壯：
- case File.read(path) do
- {:ok, binary} ->
- case :beam_lib.chunks(binary, :abstract_code) do
- {:ok, data} ->
- {:ok, wrap(data)}
- error ->
- error
- end
- error ->
- error
- end
代碼固然健壯了，然后程序結構的美感卻被破壞了。我一貫貪婪，自然不滿足于這種扭曲怪異的高質量爛代碼。若代碼的優雅能與健壯二者兼得，那就是編程世界的烏托邦了!
未必是幻想的烏托邦呢，因為Elixir從1.2版本開始就體貼地引入了with/1表達式。用它改寫前面的代碼，整容技藝甚至超過韓國整容術，因為整容后的代碼不僅美麗，而且天然，如清水出芙蓉，似乎好的代碼就該長出這樣優雅的姿容：
- with {:ok, binary} <- File.read(path),
- {:ok, data} <- :beam_lib.chunks(binary, :abstract_code),
- do: {:ok, wrap(data)}
沒有詰屈聱牙的錯落嵌套，沒有繁雜的error處理語句，with像一個高明的雕刻家，幾刀刻下，劃掉多余的石頭棱角，栩栩如生的面容就浮現出來了，渾然天成。
仿佛似曾相識?它似乎與for comprehension有著孿生的基因。嗯……千萬不要被外相給迷惑了。本質上講，for其實用于collection中對值的匹配(相當于是flatMap與filter)，而with/1則直接匹配值。例如，對于定義的這樣兩個函數：
- def ok(x), do: {:ok, x}def error(x), do: {:error, x}
for用于函數返回值的collection，然后利用模式匹配:ok，就能起到filter的作用：
- for {:ok, x} <- [ok(1), error(2), ok(3)], do: x
- #=> [1, 3]
with則直接作用在函數上，然后根據模式匹配分別處理正確場景與錯誤場景：
- with {:ok, x} <- ok(1),
- {:ok, y} <- ok(2),do: {:ok, x + y}#{:ok, 3}
- with {:ok, x} <- error(1),
- {:ok, y} <- ok(2),do: {:ok, x + y}#{:error, 1}
當error(2)無法匹配{:ok, y}時，with/1的表達式鏈條就會及時終止，并返回產生匹配錯誤的值。這樣就可以保證不讓錯誤的數據繼續傳遞，避免出現不可知的異常。這一做法其實也可以解決管道符|>的問題。
對于一個執行流程的代碼片段，管道符|>可以讓代碼充滿***的美;可惜，動人的風情之下也可能暗藏殺機。使用管道符時，倘若chain中的任意一個函數出現錯誤，就可能導致傳遞下去的數據非下一個函數所料，從而導致整個管道出現不可控的崩潰。
譬如說，我們要編寫一個發送短消息的功能：首先要獲取user信息，同時解析需要發送的短信內容，然后再發送。使用管道符的代碼如下：
- %{sms: sms, user: nil, response: nil}
- |> get_user
- |> get_response
- |> send_response
- def send_response(user, response) do
- message = user <> response #假設user與response都是字符串
- send(message)
- end
假設get_response/1出現了錯誤，例如返回一個nil，當代碼執行到send_response/2時，就可能拋出ArgumentError。
使用with/1可否解決該問題呢?例如：
- with user <- get_user(sms.from),
- response <- get_response(sms.message),
- do: send_response(user, response)
情況并不如我們預期的那樣美好，當response為nil時，程序仍然會出現錯誤。那么，改成這樣呢：
- with user <- get_user(sms.from),
- response <- get_response(sms.message),
- sent <- send_response(user, response)
- do
- sent
- else
- error -> error
- end
依舊如此!畢竟with/1并不是try/catch，它并不能捕獲執行中拋出的錯誤，然后轉向else進行錯誤處理。只有當模式匹配出現錯誤時，才會轉向else。
這其實引出Elixir的一個編程習慣，那就是對異?；蝈e誤的處理方式。
要優雅地處理錯誤，并用優雅的with/1將邏輯串聯起來，就需要重構get_user，get_response，send_response等函數。當程序邏輯正確時，返回一個tuple對象{:ok, result};如果出現錯誤，則返回{:error, error}。于是代碼變成：
- with
- {:ok, user} <- get_user(sms.from)
- {:ok, response} <- get_response(sms.message)
- {:ok, sent} <- send_response(user, response)
- do
- {:ok, sent}
- else
- {:error, :no_response} -> send_response(user, "I'm not sure what to say...")
- error -> error
- end
倘若遵循這樣一個編碼規范，每個函數并不需要檢查輸入參數是否是error，而是統一放到with/1的else中進行處理，可以省去冗余的錯誤處理代碼。
with/1將正常場景與異常場景用一種相對優雅的方式分隔開，相較于使用|>，雖然顯得還不夠直觀，但至少保證了代碼邏輯結構足夠的清晰度，干凈利落地體現了編碼意圖，且代碼還是足夠健壯的。魚與熊掌可以兼得，with/1庶幾達到了這一目標。
【本文為51CTO專欄作者“張逸”原創稿件，轉載請聯系原作者】
