ElixirでPAY.JPのライブラリ作成シリーズ② Let it crash

Let it crash

皆さん、Let it crash というシステム設計哲学をご存知ですか？
Let it crash Erlang（Elixirの基盤となる言語）の創始者であるJoe Armstrongによって提唱された考え方です。

簡単に説明すると、
エラーの定義をまず簡単に２つに区別して考えます。

例外(Exception)：実行時システムが対処方法を知らない場合
エラー(Error)：プログラマーが対処方法を知らない場合

その上で、重要な区別として以下のような考え方をします。

プログラマーが対処方法を知っている例外は「エラーではない」
例：存在しないファイルを開く → 想定内なら例外処理を書く

これは、たとえば、以下のような場合にわざわざ、エラー処理を書くのは不要という考え方です。

# 防御的なコード（避けるべき）
def asm(instruction) do
  case instruction do
    :load -> 1
    :store -> 2
    _ -> handle_unknown_instruction(instruction)  # これは必要ない
  end
end

# Let it crashアプローチ
def asm(instruction) do
  case instruction do
    :load -> 1
    :store -> 2
  end
end

プログラマーが「どうすべきか分からない」状況では、わざわざ防御的なコードを書かない
システムが自動的に提供するエラー処理の方が、多くの場合は適切

防御的すぎるコードは以下の観点で不要という考え方です。

• 可読性を下げる
• コアの機能を分かりにくくする
• エラーメッセージが標準のものより悪くなることもある

でもクラッシュしたら大変じゃない？と思うかもしれません。
そうです。クラッシュしたままにしたら大変です。なので、重要なのは

回復可能な形でクラッシュさせる

という設計です。ElixirやErlangはこの思想での設計を担保してるのは、
Erlangのランタイム設計によって支えられているからです。
ただ、考え方は他の言語でも応用可能です。

さて、次回はこのErlang/Elixirのランタイム設計の特徴について詳しく見ていきます。