1. 導入：なぜAesonのエラーハンドリングが重要なのか
実務で外部APIや設定ファイルを扱う際、JSONの構造が期待通りである保証はどこにもありません。「フィールドが欠けている」「型が違う」「値が範囲外」といった問題は日常茶飯事です。HaskellのAesonライブラリにおいて、単に `decode` を使うだけでなく、`parseEither` を活用してエラーの発生箇所を特定することは、システムの堅牢性を高めるために不可欠です。本記事では、不透明なパースエラーを「詳細な情報」へと変換する手法を解説します。
2. 基礎知識：Aesonのパースエラーの仕組み
Aesonはデフォルトで `FromJSON` 型クラスを利用してJSONを変換しますが、単なる `Maybe` での処理では「どこで」「なぜ」失敗したのかが隠蔽されてしまいます。ここで重要になるのが `Parser` モナドです。このモナド内で失敗が発生すると、エラーパス情報（どのキーで何が起きたか）が蓄積されます。`parseEither` は、この `Parser` の結果を `Either String a` として取り出すための関数です。
3. 実装/解決策：parseEitherによる詳細なエラー取得
`decode` 関数は内部で `parseMaybe` を使用しているため、エラー詳細は破棄されます。実務では、`aeson-better-errors` のようなライブラリを使う手もありますが、標準の `Data.Aeson.Types` にある `parseEither` を使うだけでも十分な情報を得られます。`fromJSON` と組み合わせることで、パース処理を明示的に制御します。
4. サンプルプログラム
以下は、ユーザー情報をパースする際のコード例です。型が一致しない場合に、詳細なエラーメッセージを返す仕組みを実装しています。
{-# LANGUAGE OverloadedStrings #-}
import Data.Aeson
import Data.Aeson.Types (parseEither)
import qualified Data.ByteString.Lazy.Char8 as LBS
— パース対象のデータ型
data User = User { name :: String, age :: Int } deriving (Show)
— FromJSONインスタンスの定義
instance FromJSON User where
parseJSON = withObject “User” $ \v -> User
<$> v .: “name”
<> v .: “age”
main :: IO ()
main = do
— ageが文字列になっている不正なJSONデータ
let jsonInput = “{\”name\”: \”Alice\”, \”age\”: \”twenty\”}”
let decoded = decode jsonInput :: Maybe Value
case decoded of
Nothing -> putStrLn “JSON自体の形式が不正です。”
Just val -> do
— parseEitherを使ってエラー詳細を取得
case parseEither parseJSON val of
Left err ->
— 失敗したパスと原因が詳細に出力される
putStrLn $ “パースエラー発生: ” ++ err
Right user ->
print user
5. 応用・注意点：現場で陥りやすいバグの回避策
注意点1：エラーメッセージの可読性
`parseEither` が返すエラー文字列には、`”key1.key2″` のようなパス情報が含まれます。ログに出力する際は、このパス情報をそのまま監視ツール（SentryやDatadogなど）に送ることで、どの外部サービスから不正なデータが飛んできているか即座に特定できます。
注意点2：柔軟な型変換の罠
`withObject` 内で `.:?` を使ってオプショナルなフィールドを扱う場合、`Nothing` なのか `失敗` なのかの区別が曖昧になりがちです。必須フィールドには必ず `.:` を使用し、`parseEither` で全体を包むことで、意図しないデータ欠損を早期に検知できる設計を心がけましょう。
実務においては、「パースは必ず失敗する可能性がある」という前提に立ち、`Either` を使ったパイプラインを構築することが、デバッグコストを最小化する唯一の道です。
コメント