1. 導入: なぜDBエラーを例外で扱ってはいけないのか
実務におけるWebアプリケーション開発では、DBの制約（一意性制約など）によるエラーは「異常系」ではなく、ユーザーの操作によって発生しうる「正常な業務フローの一部」であることがほとんどです。HaskellのPersistentライブラリにおいて、安易に例外（Exception）を投げると、呼び出し元でそれを捕捉し忘れるリスクがあり、システムの堅牢性が低下します。本記事では、例外を型（Either）に変換し、コンパイル時にエラー処理を強制させる設計手法を解説します。
2. 基礎知識: 例外 vs 値によるハンドリング
Haskellにおいて、例外は「副作用」として隠蔽されがちですが、`Either`型や`Maybe`型を使うと、エラーの存在を型シグネチャで明示できます。Persistentには標準で`insertUnique`のような、重複時に`Nothing`を返す便利な関数が用意されています。これらを活用することで、`try-catch`ブロックという命令的なコードから脱却し、関数型らしい宣言的なエラーハンドリングが可能になります。
3. 実装/解決策: insertUniqueを用いた値による判定
一意性制約違反を処理するために、例外を投げる`insert`ではなく、安全な`insertUnique`を使用します。この関数は、レコードが既に存在する場合に`Nothing`を返し、成功した場合には`Just key`を返します。これに`Maybe`を`Either`へ変換する関数を組み合わせることで、エラー発生時に「なぜ失敗したのか」という情報を呼び出し元へ確実に伝播させることができます。
4. サンプルプログラム: 型安全なユーザー登録関数
{-# LANGUAGE GADTs, TypeFamilies, OverloadedStrings #-}
import Database.Persist
import Database.Persist.Sqlite
import Control.Monad.IO.Class (liftIO)
— ユーザーを登録し、結果をEitherで返す関数
— 成功時はRight Key、重複時はLeft “ユーザーが既に存在します” を返す
registerUser :: User -> SqlPersistT IO (Either String (Key User))
registerUser user = do
maybeKey <- insertUnique user
case maybeKey of
-- insertUniqueがNothingを返した＝一意性制約に抵触したと判断
Nothing -> return $ Left “ユーザーが既に存在します”
— 成功した場合はKeyをラップして返す
Just key -> return $ Right key
— 実行例
runExample :: SqlPersistT IO ()
runExample = do
let newUser = User “haskell_user” “email@example.com”
result <- registerUser newUser
case result of
Left err -> liftIO $ putStrLn $ “エラー発生: ” ++ err
Right key -> liftIO $ putStrLn $ “登録完了: ” ++ show key
5. 応用・注意点: 現場で役立つアドバイス
運用上の注意点として、DBの制約エラー以外の予期せぬエラー（接続断など）については、依然として例外が発生する可能性があります。業務的なバリデーション（重複チェック）は`insertUnique`で型安全に処理しつつ、ネットワーク障害等のシステムエラーは上位層のミドルウェアで一括捕捉する「階層的なエラーハンドリング」を意識してください。また、複雑な制約エラーを扱う場合は、`Either`の代わりにカスタムの`Error`型を定義し、どのフィールドでエラーが起きたかを構造的に保持すると、フロントエンドへのエラー通知が非常にスムーズになります。
コメント