導入: なぜエラーの黙殺が危険なのか
関数型プログラミングにおいて、`catMaybes` や `rights` といった関数は、リストから有効な値だけを抽出する非常に便利なツールです。しかし、これらを安易に使うと、本来解決すべき「予期せぬ失敗」までを静かに消し去ってしまうリスクがあります。本記事では、意図的なフィルタリングと、見逃してはならないエラーを区別し、堅牢なプログラムを書くためのヒントを解説します。
基礎知識: なぜ「捨ててしまう」のか
関数型言語では、エラーを例外として投げるのではなく、`Maybe` 型（値があるか、何もないか）や `Either` 型（成功か、失敗の理由があるか）で表現します。
例えば、データのリストから「成功したものだけを取り出す」際に、`catMaybes` を使うと `Nothing`（失敗）が自動的に除外されます。これは一見スマートですが、「なぜ失敗したのか」という情報も同時に捨てていることに注意が必要です。
実装/解決策: 「ログ」と「分離」の原則
エラーを黙殺しないための鉄則は、「フィルタリングする前にログを出す」ことと、「成功と失敗を明確に分離して追跡すること」です。失敗を単なる `Nothing` として扱うのではなく、失敗の原因を記録（ロギング）し、その上で必要な処理を継続するように設計します。
サンプルプログラム
以下は、Haskellにおける「エラーを黙殺せず、ログに残しながら処理を続行する」ためのパターンです。
import Data.Maybe (catMaybes)
import Debug.Trace (trace)
-- 失敗する可能性のある処理
parseData :: String -> Maybe Int
parseData str =
case reads str of
[(n, "")] -> Just n
_ -> Nothing -- ここで失敗が発生
-- エラーを黙殺せず、ログを出しながらフィルタリングする関数
processData :: [String] -> [Int]
processData inputs = catMaybes $ map logIfNothing inputs
where
logIfNothing x =
case parseData x of
Just val -> Just val
Nothing -> trace ("警告: 無効なデータが検出されました: " ++ x) Nothing
main :: IO ()
main = do
let rawData = ["10", "abc", "20", "invalid"]
let results = processData rawData
print results -- 成功した値のみが出力され、コンソールには警告が出る
応用・注意点: 現場で役立つポイント
1. 意図的なフィルタリングか確認する: ユーザー入力のバリデーションなど、最初から「捨てることが仕様」である場合は、`catMaybes` を使っても問題ありません。しかし、システム間のデータ連携など、データが壊れていることが異常事態である場合は、黙殺してはいけません。
2. トレースよりもロガーを使う: 上記のサンプルでは `trace` を使用しましたが、実務では適切なロギングライブラリを使用し、エラーの発生頻度を監視（モニタリング）できるようにしてください。
3. 型による表現の強化: もし「失敗の理由」を後で追跡する必要があるなら、`Maybe` ではなく `Either String Int` を使うべきです。`Either` を使えば、どのデータがどのような理由で失敗したのかを完全に保持したまま処理を継続できます。
エラーの黙殺は「ゴミを絨毯の下に隠す」行為に似ています。隠すなら、せめて「どこに何を隠したか」のメモ（ログ）を残す習慣をつけましょう。
コメント