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