ScalaでWebアプリケーションのエラー処理を綺麗に書く

Play Frameworkにおいて、POSTリクエストから得られたbody中のパラメータをもとに何か処理をするというよくあるコードを、ちょっと整理して見やすくする方法を学んだのでメモがてら御シェアさせていただきます。Playのリクエストハンドラを書くときに頻繁に現れたので、例がPlayのコードになっているけど、内容的にはScala全般的な話だと思う。Scalaプロみたいな人にはまったく新しいことはないと思う。

本題と関係ないけど、YAPCでScalaの話をするかもしれません。言語自体の話よりかは採用理由とか開発フローの話を、これまでのPerlでのWeb開発を踏まえて話す感じになりそう。Scala In Perl Company : Hatena - YAPC::Asia Tokyo 2014

さて、本題ですが、話題の対象になるのは以下の様なPlayFrameworkのコードです。

def update = Action { implicit req =>
  req.body.asFormUrlEncoded.fold(BadRequest("Wrong POST body")) {
    data =>
      Form(tuple( "id" -> number, "title" -> text, "body" -> text )).
        bindFromRequest(data).value.fold(BadRequest("Wrong parameters")) {
          case (id, title, body) =>
            find(id).fold(NotFound("No entry found")) {
              entry =>
                save(id, title, body)
                Ok("Success!")
            }
      }
  }
}

上の例では、以下の3つの処理が、Option型の値を返却します。返却されたOption型の値がNoneだった場合( = 計算に失敗した場合)、処理を中断してエラーレスポンスを返しています。

(Scalaでは失敗するかもしれない計算結果はOption型に包んで扱います。Option型を使うことで、値が存在することを確認しないかぎり、包まれた値を利用できません。詳しくはゆるよろさんの記事が詳しいのでおすすめです。)

req.body.asFormUrlEncoded(PlayのAPI) bodyをapplication/x-www-form-urlencodedとして読み込みパラメータを得る
- 結果がNoneだったら: "Wrong POST body"という内容のBadRequestレスポンスを返す
Form(...).bindFromRequest(data).value(PlayのAPI) によりFormの定義にbodyから得られたパラメータを結びつけて値を得る
- 結果がNoneだったら: "Wrong parameters"という内容のBadRequestレスポンスを返す
find(id)(独自に定義した関数) によりパラメータから得られた値を使ってentryを得る
- 結果がNoneだったら: "No entry found"という内容のNotFoundレスポンスを返す

Option型を処理するのには比較的コンパクトにかけるfoldメソッドを利用しています。Option型のfoldメソッドはOption型の値がNoneだった場合は一つ目の引数リストの値を、Someだった場合は二つ目の引数リストに与えられた関数に、包まれた値を渡して評価した結果を返します。

Option型を使うことで、漏れ無く計算が失敗した場合の処理を書くことができていますが、ご覧のとおり読みにくいです。どの部分が本来行いたい処理で、どの部分がエラー処理なのかが判別しづらくなっています。

そこで、Option型はflatMapメソッドを実装していますから、forを使って整理してみることにします。

def update2 = Action { implicit req =>
  (for {
    data <- req.body.asFormUrlEncoded
    form <- Some(Form(tuple( "id" -> number, "title" -> text, "body" -> text )))
    (id, title, body) <- form.bindFromRequest(data).value
    entry <- find(id)
  } yield (id, title, body)) match {
    case None =>
      BadRequest("Something wrong")
    case Some((id, title, body)) =>
      save(id, title, body)
      Ok("Success!")
  }
}

ご覧のようになりました。パラメータの準備と検証をforの中で行い、いずれかが失敗した場合にはcase分のNoneの節が、すべて成功した場合にはSomeの節が実行される、という読むことができます。正常系と異常系のコードを分けて読むことができ、比較的わかりやすくなりました。

ただ、この例には問題があります。Option型の値を連ねたfor文からは、計算が失敗した場合に、いずれかの計算が失敗したことはわかりますが、どの計算が失敗したのかがわかりません。そのためエラー処理を分岐できず、とりあえず、"Something wrong"という内容でBadRequestを返すという雑なエラー処理をするはめになっています。

さて、このような計算が失敗したときの理由も取り扱いたいときには、Either型を使うのが便利であると、すごいHaskellたのしく学ぼう!にはありました。独習ScalazのEitherの解説をよめば、Scalaでの使い方もわかります。

ここではOption型の値をtoRightメソッドを使って、Either型に変換し、それぞれの計算で別のエラーを取り扱えるようにしてみます。ScalaではEither型にはflatMapが実装されていないので、Either型のrightメソッドを呼び出して、Either型のサブクラスのRightProjection型に変換して使います。RightProjection型のflatMapメソッドは値がRightである場合に計算を継続します。

Option型の値をRightProjection型の値に変換することで、計算結果がRightであれば計算を継続し、Leftの場合は計算を途中で中止してその値を返すという振る舞いを実現できます。

def update3 = Action { implicit req =>
  (for {
    data <- req.body.asFormUrlEncoded.toRight(
      BadRequest("Wrong POST body")).right
    form <- Right(Form(tuple( "id" -> number, "title" -> text, "body" -> text ))).right
    params <- form.bindFromRequest(data).value.toRight(
      BadRequest("Wrong parameters")).right
    entry <- find(params._1).toRight(
      NotFound("No entry found")).right
  } yield params) match {
    case Left(error) =>
      error
    case Right((id, title, body)) =>
      save(id, title, body)
      Ok("Success!")
  }
}

ご覧のようになりました。計算の見通しが良いまま、それぞれの計算ごとに失敗した場合の計算結果を返すことができるようになりました。RightProjection形のfilterメソッドの制限か何かで、forの中でパターンマッチが使えないのが惜しい。

追記: id:xuwei さんに教えていただいたところによると、Eitherについて自然なfilterを定義できない(Optionを返すようなMonadPlusに適合しないシグニチャになってる)ために、forの中で利用できないとのことでした。ありがとうございます。参考: HaskellのdoとScalaのfor式とEitherとMonadPlus - scalaとか・・・

追記2: ScalazのEither型相当の\/型はfoldMapはRight優先で実装されているので、それを使うとちょっとスッキリする。

import scalaz._
import Scalaz._

def update5 = Action { implicit req =>
  (for {
    data <- req.body.asFormUrlEncoded \/>
      BadRequest("Wrong POST body")
    form <- Form(tuple( "id" -> number, "title" -> text, "body" -> text )).right
    params <- form.bindFromRequest(data).value \/>
      BadRequest("Wrong parameters")
    entry <- find(params._1) \/>
      NotFound("No entry found")
  } yield params) match {
    case -\/(error) =>
      error
    case \/-((id,title,body)) =>
      save(id, title, body)
      Ok("Success!")
  }
}

インデントが深くなるのが嫌であれば、エラーが発生した時点でreturnすれば分かりやすいしええやん?という風にも思えます。例えば以下の様になります。

def update4 = Action { implicit req =>
  def handle: Result = {
    val dataOption = req.body.asFormUrlEncoded
    if (dataOption.isEmpty) {
      return BadRequest("Wrong POST body")
    }
    val form = Form(tuple( "id" -> number, "title" -> text, "body" -> text ))
    val valueOption = form.bindFromRequest(dataOption.get).value
    if (valueOption.isEmpty) {
      return BadRequest("Wrong parameters")
    }
    val (id, title, body) = valueOption.get
    val entryOption = find(id)
    if (entryOption.isEmpty) {
      return NotFound("No entry found")
    }

    save(id, title, body)
    Ok("Success!")
  }
  handle
}

たしかに、シンプルな手続きの並びでわかりやすくはあります。ただし、Option型の中の値が入っているかをチェックする部分と使う部分が別になってしまい、コンパイル時に値の取り出しが安全かどうかを判定できなくなってしまいました(getを使っているためランタイムエラーの可能性が残る)。わざわざコンパイラによるチェックがされない方法をとるメリットはなさそうです。Actionが引数にクロージャをとる都合上、returnを使うために内部に関数を定義しないと行けないのもつらいところですね。