漂亮的with，鱼与熊掌可以兼得

with/1将正常场景与异常场景用一种相对优雅的方式分隔开，鱼与熊掌可以兼得，with/1庶几达到了这一目标。

[[187783]]

假设要加载磁盘上的一个文件，并以二进制形式读取文件的数据。若要从健壮性的角度考虑，需得考虑两种异常情况：

• 加载文件失败，例如给定的文件路径并不存在该文件
• 读取文件数据失败，例如磁盘扇区有故障

显然，生活中总是存在着例外，我们不能乐观对待，还得未雨绸缪，唯有对这些异常情况做充分判断，由代码组成的软件系统才够健壮：

caseFile.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则直接匹配值。例如，对于定义的这样两个函数：

defok(x),do:{:ok,x}deferror(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
defsend_response(user,response)do
message=user<>response#假设user与response都是字符串
send(message)
end

假设get_response/1出现了错误，例如返回一个nil，当代码执行到send_response/2时，就可能抛出ArgumentError。

使用with/1可否解决该问题呢?例如：

withuser<-get_user(sms.from),
response<-get_response(sms.message),
do:send_response(user,response)

情况并不如我们预期的那样美好，当response为nil时，程序仍然会出现错误。那么，改成这样呢：

withuser<-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'mnotsurewhattosay...")
error->error
end

倘若遵循这样一个编码规范，每个函数并不需要检查输入参数是否是error，而是统一放到with/1的else中进行处理，可以省去冗余的错误处理代码。

with/1将正常场景与异常场景用一种相对优雅的方式分隔开，相较于使用|>，虽然显得还不够直观，但至少保证了代码逻辑结构足够的清晰度，干净利落地体现了编码意图，且代码还是足够健壮的。鱼与熊掌可以兼得，with/1庶几达到了这一目标。

【本文为清一色专栏作者“张逸”原创稿件，转载请联系原作者】

戳这里，看该作者更多好文