Erlang/Elixir鼓勵(lì) let it crash的編程哲學(xué)。此刻不是要記錄什么是let it crash，而是寫(xiě)代碼時(shí)想到了一個(gè)小細(xì)節(jié)。
這個(gè)小細(xì)節(jié)就是，函數(shù)調(diào)用時(shí)，盡量捕獲到你希望獲得的返回值。
例如你依賴(lài)的某個(gè)第三方庫(kù)的api可能是這樣：
@spec foo -> :ok | {:error, reason}
而如果你對(duì)代碼過(guò)于自信、認(rèn)為返回值肯定是:ok的話，很可能就會(huì)這么調(diào)用：
def bar do
foo
end
上述代碼是有危險(xiǎn)的，它沒(méi)有捕獲函數(shù)的返回值。
假設(shè)foo/0是個(gè)保存文件的函數(shù)，而保存文件一般情況下肯定會(huì)成功，所以代碼編寫(xiě)者慣性思維地認(rèn)為foo/0一定會(huì)返回:ok，但若是在磁盤(pán)順壞、空間剩余不足等情況下也有可能使得該操作失敗，也就是說(shuō)，這個(gè)bar/0實(shí)現(xiàn)有潛在危險(xiǎn)！
我認(rèn)為對(duì)bar/0比較好的改寫(xiě)是：
def bar do
:ok = foo
end
僅僅是加了一個(gè)match。
加了這個(gè)match，若foo/0返回了我們討厭看到的{:error, reason}，則該進(jìn)程就會(huì)報(bào)異常，也就是let it crash。之后我們檢查日志，就能發(fā)現(xiàn)一些潛在的危險(xiǎn)，比如磁盤(pán)順壞，就立刻修復(fù)磁盤(pán)或者遷移文件等。
再舉個(gè)例子：
# 第三方庫(kù)
@spec foo -> :ok
# 調(diào)用者代碼
def bar do
foo
end
這次的調(diào)用總不會(huì)出問(wèn)題了吧？你看foo/0肯定會(huì)返回:ok的，再去捕捉它的返回值，這不是多此一舉嗎？
那我想問(wèn)，如果這個(gè)第三方庫(kù)版本升級(jí)，foo/0這個(gè)api也升級(jí)為如下形式了呢？這不是不可能吧~
@spec foo -> :ok | {:error, reason}
所以，更穩(wěn)妥的寫(xiě)法還是加個(gè)match捕獲期望的函數(shù)返回值吧。
// 其實(shí)上述例子都不怎么好，可我現(xiàn)在手頭又沒(méi)有比較好的例子，先湊活著這樣吧
