假設要加載磁盤上的一個文件，并以二進制形式讀取文件的數據。若要從健壯性的角度考慮，需得考慮兩種異常情況：
- 加載文件失敗，例如給定的文件路徑并不存在該文件
- 讀取文件數據失敗，例如磁盤扇區有故障
顯然，生活中總是存在著例外，我們不能樂觀對待，還得未雨綢繆，唯有對這些異常情況做充分判斷，由代碼組成的軟件系統才夠健壯：
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的一個編程習慣，那就是對異常或錯誤的處理方式。
要優雅地處理錯誤，并用優雅的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庶幾達到了這一目標。
參考：
