エラーハンドリング・クロニクル #nds41

はじめに

プログラミング技術の歴史は、ありとあらゆる歴史がそうであるように、いろんな「史観」で眺めることができます。ならば、プログラミング技術の歴史を、「エラーハンドリングとの戦い」という視点から見ることもできるのではないでしょうか。本日は、エラーハンドリングとの戦いの歴史を俯瞰することで、エラーハンドリングの勘所について考えていこうと思います。

なお、このエントリはNDSという勉強会の第41回で発表した内容と同一です。

Cの時代

Cの時代のエラーハンドリングでは、関数の返り値と、グローバル変数errnoを見ることで処理が成功したか失敗したかを見るのが一般的でした。

例として、文字列をlongに変換するstrtol関数をmanで引いてみましょう。すると、だいたい以下のようなことが書かれています。

• 変換に失敗すると、0を返す
• 変換に失敗した場合、グローバルな変数であるerrnoに以下の定数を格納する
  • invalidな文字列を渡された：EINVAL
  • longã‚’overflowしたりunderflowする数を渡された：ERANGE

さて、一見してとてもシンプルな仕様ですが、現代的な視点からみてみると、いくつか気になることがありそうです。ざっと挙げてみると……

• 関数を呼び出したあと、エラーであるかどうかを手動でチェックする必要があるし、仮にチェックしなかったとしてもコンパイラが怒ってくれるわけではない

int main(int argc, char *argv[]){
  long l = strtol("string");
 
  // なんかこうごちゃごちゃといろいろやる
 
  some_function(l); // ここでおかしなことになる
  return 0;
}

これは結構怖いですね。たとえば"String"みたいな文字列をstrtolに渡して、エラーチェックをしなかった場合、0という数だと解釈されたまま、プログラムは動き続けます。そして、どこかこのstrtolを呼び出したところから遠く離れたところで、いきなりプログラムがクラッシュします。バグを入れ込んでしまったところと、バグが発見されたところが遠く離れているとき、デバッグは困難を極めます。うーん。おそろしい。

では、必ずエラーを手動でチェックすればそれで問題は解決でしょうか。そんなことはありません。たとえばあなたが文字列と文字列を受け取り、それをlongとして解釈して足す関数を含むライブラリ作成しているとしましょう。このとき、もしstrtolにinvalidな文字列を渡してEINTVALが帰ってきても、自分ではそのエラーをどうハンドリングすべきか、ということはわかりません。なぜかというと、「変な値入れられた時にそれをどう扱うべきか」というのは、ライブラリが決めるべきことではなくて、アプリケーションの要件によって決まることだからです。

なので、あなたはあなたが作成している関数の利用者に対して「invalidな文字列が渡されたよ」というエラーを通知する必要があるわけです。つまり、エラーを上流に伝播させる必要があるわけです。そして、このようなシチュエーションは決して珍しいものではありません。そのたびにあなたは起こりうるエラーに対してすべてエラーコードを定義して、エラーの場合の返り値を決めて、という作業をしなければいけません。そして、あなたの書くコードは本質的な処理よりもエラーハンドリングのためのコードによってどんどん太っていきます。

つまり、このやり方では、

• エラーを無視しやすい
• エラーを上流に伝播させるのがだるいしむずかしい

という問題があるわけです。

そして、それだけではありません。まだ気になる点はあります。それは、

• エラーの詳細がグローバル変数に格納されている

という点です。グローバル変数は、いつ書きかわるかわかりません。なので、errnoをあとから参照したい場合はそれ用の変数を作ってコピーしておく、という回避策が一般に取られています。

int main(int argc, char *argv[]){
  long l = strtol("string");
  int strtol_err = errno; // コピーしとかないといけない
 
  // ちょっとなんかやる間にerrnoが書きかわる可能性‥‥
 
  if (strtol_err== EINVAL) {
    // エラー処理
  } else if (strtol_err == ERANGE) {
    // エラー処理
  }
 
  return 0;
}

シングルスレッドで動いているならば、「次の行で必ずチェック、あるいはコピーする」ということを徹底すれば（それだって結局人間がやらなければならないのですけれど）問題にはならないでしょう。しかし、もしもこれがマルチスレッドで動いていたら？errnoは本当に「どのタイミングで書きかわるかわからない」ものになります。

さらにもうひとつ問題があります。それは「エラー時にリソースの解放をするのが煩雑」という点です。

エラーになってしまったとき、mallocで確保していたものをfreeせずに早期returnなどをすると、正常系では解放されるリソースが解放されなかったりします。これを防ぐためによるあるパターンは、関数の後ろのほうにリソース解放の処理を書いておき、返り値は変数に入れておき、gotoでリソース解放のところにすっ飛ぶパターンです。

int nyan(){
  int *p1 = (int *)malloc(sizeof(int))
  int *p2 = (int *)malloc(sizeof(int))
  int *p3 = (int *)malloc(sizeof(int))
  int retval = 0;

  // ごちゃごちゃなんかやる
  
  //！エラーが起こった！  
  if (err) {
     retval = -1; // エラーコードを入れて
     goto cleanup; //cleanupにすっ飛ぶ
  }
  
  //正常系は続く
  
  retval = 1; //正常系の場合の返り値を入れて
  
cleanup:
  free(p1);
  free(p2);
  free(p3);
  return retval;
}

エラー処理周りのコードだけで、こんなに大きな関数になってしまいました。バグを入れ込みそうで怖いですね！一時期話題になったApple史上最大のセキュリティバグ、goto fail; なんかはこのパターンをつかってたやつです。

Cスタイルのエラーハンドリングの問題点については、おおまかにこんなところでしょうか。

一度まとめておくと、

• エラーを無視しやすい
• エラーを上流に伝播させるのがだるいしむずかしい
• エラーの内容がグローバル変数に格納されている
• リソース管理が絡むと煩雑になる

ですね。

例外の時代

さて、Cの時代のような問題に対抗するために、人間は例外という新しい武器を作り出しました。例をあげながら、上述の問題点がいかに解決されているのかを見てみましょう。

• エラーを無視しやすい

例外をrescue(キャッチ)しわすれるということはあり得ますが、その場合もプログラムはすぐさまクラッシュしてくれるので、エラーを無視してしまっても、「間違えた内部状態のままプログラムが進んでしまって、バグを入れ込んだところと遠く離れたところでいきなりクラッシュする」というようなことは防げるようになりました。

class WanError < StandardError; end

def wan
  raise WanError, "エラーだよ！！！"
end

wan # rescueしていないのでここでプログラムは止まってしまう

• エラーを上流に伝播させるのがだるいしむずかしい

例外をraiseしてそれをrescueしなかった場合、例外はコールスタックを上流に向かってどんどん突き進んでいきます。なので、何も書かなくても nyan の中でよんだ wan のエラーを main で捕まえることができます。

class WanError < StandardError; end

def nyan
  wan
end

def wan
  raise WanError, "エラーだよ！！！"
end

begin
  nyan
rescue WanError => e # wanの中で発生したエラーをここで捉えられる
  p e
end

• グローバル変数errnoの存在

例外が起こるたびに例外オブジェクトを発生させるので、グローバル変数にエラーを入れておく必要がありません。

• リソースお片付け問題

ensureやfinaly（例外が起こっても起こらなくてもかならず実行される部分）があるので、そこでお片付けすればシンプルです。

r = Resource.new
begin
  # do something
rescue => e
  # do something
ensure
  r.close
end  

さて、いいことづくめであるような気がする例外機構ですが、近年、この例外機構をもってしても解決できない問題が人類を襲いました。

• キャッチし忘れ問題

例外をキャッチしわすれると、アプリは死にます。それはもう見事に簡単に死にます。Javaの検査例外は例外のキャッチし忘れをコンパイル時に見つけてくれる仕組みですが、批判も多い機能ですね。今回はちょっと分量的に無理なので検査例外の話には立ち入りません。

• 非同期処理との相性の悪さ

一般に、非同期処理が絡むと、例外の扱いはかなり難しくなってきます。というのも、(たとえば)スレッドAで起こった例外は、そのままスレッドBでキャッチすることはできません。これは、スレッドAとスレッドBが別のコールスタックを持っていることを考えれば当然のことです。そのため、スレッドをまたいだ例外の取り扱いというのは非常にむずかしいものとなります。Javaはそれに対して Callable と Future という回答を出し、それは一定の成果を上げていると言えそうです（このあたりも詳しく入り込む余裕がないので入り込みません）。しかし、たとえば goroutine のように、非同期なタスクから連続的に値を受け取りたいときなどはどうすればいいでしょうか？ Runnable では依然として別スレッドの例外を補足する方法はなく、非同期処理と例外機構というのは、やはり結構相性が悪いもののようです。

Eitherの時代

さて、Cスタイルのエラーハンドリングに対して、例外とは別の方向から回答を出したのが、関数型界隈でよく使われているEitherというデータ型です。

Scalaの例で説明しましょう。Scalaにおける Either というのは、LeftかRightどちらかの値を持つデータ型です。LeftとRightはコンテナになっていて、どんな値でもその中に入れることができます。

Eitherの使い方としては、正常に処理が成功した場合はRight（正しい、という意味のRightと掛けている）に値を突っ込んで、失敗した場合は失敗の理由などを表すオブジェクトをLeftに突っ込んで返します。こんな感じ。

def divide(x:Int, y:Int): Either[String, Int] = {
  if (y == 0) {
    Left("can't divide by zero")
  } else {
    Right(x / y)
  }
}

divide(2, 2) // => Right(1)
divide(0, 0) // => Left("can't divide by zero")

Cスタイルと同じく、値としてエラーかどうかを返すスタイルです。が、Eitherの場合どのようにCスタイルの問題が解決されているのか見てみましょう。まず、

• エラーを無視しやすい

という点は解決されています。というのも、Eitherの中身はそのままでは使えません。なんらかの方法で取り出す必要があります。

たとえば、Eitherの中身は、パターンマッチで取り出すことができます。

val either = divide(2, 2)

either match {
  case Right(x) => println(x)
  case Left(message) => println(message)
}

このとき、RightだけでパターンマッチしたりLeftだけでパターンマッチしようとすると、コンパイラが「caseが網羅的じゃないよ」と怒ってくれます。終始こんな感じで、Leftを無視してRightの中身だけを扱おうとするとコンパイラに怒られる仕組みが揃っています。

次に

• エラーを上流に伝播させるのがだるいしむずかしい

という問題について見てみましょう。Eitherにはrightというメソッドがあって、これを呼ぶとRightProjectionというものが取得できます。これは「Eitherのright側を正当なものとして扱うよ」と決めたもの、のようなものです。このRightProjectionにはmapメソッドが生えていて、そのmapメソッドは「Leftの場合はそのままLeftを返して、Rightの場合は引数に指定した計算を行う」という挙動をします。

def divideAndDouble(x: Int, y:Int): Either[String, Int] = divide(x, y).right.map(_ * 2)

divideAndDouble(2, 2) // => Right(2)
divideAndDouble(0, 0) // => Left("can't divide by zero")

このように、map（やflatMap）を利用することで簡単にエラーを伝播させることができます（for式やモナドについては触れません。興味があれば調べてください）。

• エラーの詳細がグローバル変数に格納されている

毎回Eitherを作るのでグローバル変数は駆逐できます。

• リソースの解放問題

これはEitherによって解決されるものではないですが、関数型スタイルではリソースの確保や解放は副作用とみなします。関数型スタイルでは、副作用をなるべく局所的にまとめて、ロジックから分離するという別の方法で解決しています（雑な説明ですがここに入り込むとまた時間がかかるのでこれも詳しく気になるひとは調べてください）。

というわけで、Cスタイルの問題点はどうやらEitherでだいぶ解決できそうです。

ここからさらに、例外が持ち込んでしまった問題点をEitherがどのように解決しているかも見てみましょう。

• キャッチしわすれ問題

上述の通り、エラーを無視しようとすると、コンパイラが怒ってくれますし、検査例外ほど煩雑でもありません。

• 非同期処理との相性問題

例外機構は制御構文ですが、Eitherは単なるデータ型です。スタックを飛び越えたりしないし、「普通の値」として扱えます。なので、例外機構よりも素直に非同期処理においてエラーを扱うことができます。何度も言いますが、単なる値ですから。

おまけ・現代プログラミング言語の異端児、golangについて

golangも、例外機構以外の方法でエラーを扱う言語です。これは、goroutineの存在が大きいのではないでしょうか。goroutineはJavaのFutureとかと異なり、goroutine同士でデータをやりとりするために channel を使います。このとき、素直な例外機構はまったく役に立ちませんよね。

そこでgolangは、返り値を複数持てることを利用して、最初の返り値に正常系の返り値、2つめの返り値に異常系の時のエラー値を返す、という「慣習」をつくることにしてしました！！！！

file, err := os.Open(filename)

これはかなり大胆な考えかたですが、実は結構バランスのとれた解だと思います。

まず、うっかりerrを受け取り忘れると、コンパイル時に怒られます

f := os.Open(filename) //multiple-value os.Open() in single-value context

さらに、errを受け取ったとして、それを無視してもコンパイル時に怒られます

f, err := os.Open(filename)
// このあとなにもしないと、err declared and not usedと怒られる

さらに、リソースお片付け問題に関しても、defer を導入することで解決しています。

func openAndClose(filename string) {
    f, err := os.Open(filename)
    // snip
    defer f.Close() // openAndCloseを抜けるときに必ず呼ばれる
    // snip
}

現代的な言語なのにいわゆる例外がないの！！！！って最初はびっくりしますが、goroutineとの絡みを考えると非常にバランスのとれた設計だと言えそうな気がしますし、ある意味「あんまり堅苦しくないしモナドじゃないEither」みたいな立ち位置で、かなり面白いですね！

まとめ

エラーハンドリングのパラダイムをいろいろ見てみました。「どれが最高の正解」ってことはないけれど、それぞれのプラットフォームやパラダイムがどう問題を解決しようとしているのかを知ることで、より安全なアプリケーションを書く助けにはなるのではないでしょうか。