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