動いているから大丈夫だと思っていた
ツールもスクリプトも、
問題なく動いているように見えていました。
入力も想定どおり。
結果も合っている。
だから、
エラー処理は「後でいい」と判断しました。
エラーは突然やってくる
ある日、いつもと少し違うデータが来ました。
- 空のCSV
- 数値だと思っていた列に文字
- ファイルが存在しない
その瞬間、スクリプトは止まりました。
理由は単純で、
想定外を一切考えていなかった からです。
最初に書いていたコード
当時のコードは、こんな形でした。
def process(file):
rows = read_csv(file)
total = 0
for r in rows:
total += int(r["value"])
return total
入力が正しければ問題ありません。
でも、前提が一つでも崩れると即エラーです。
後から追加したエラー処理
慌てて、最低限の対処を入れました。
def process(file):
try:
rows = read_csv(file)
total = 0
for r in rows:
total += int(r["value"])
return total
except Exception as e:
print(f"error: {e}")
return None
これで止まらなくはなりましたが、
今度は 何が起きたのか分からない 状態になりました。
本当に足りなかったもの
振り返ると、
足りなかったのは try/except そのものではありません。
- どこで失敗していいのか
- 失敗したらどうするのか
- どこまでを正常とするのか
この設計が、最初から無かったのです。
考え方を変えた
そこで、考え方を変えました。
- 失敗は起きる前提にする
- エラーは隠さず、記録する
- 「止まる」と「続ける」を分ける
def process(file):
rows = read_csv(file)
total = 0
for r in rows:
try:
total += int(r["value"])
except ValueError:
log_error(r)
return total
すべてを握りつぶさず、
扱える形で残す ことを優先しました。
作って分かったこと
この経験で分かったのは、
- エラー処理は後付けしにくい
- 「止まらない」と「安全」は違う
- エラーは設計の一部
ということです。
おわりに
この話は、
エラー処理を後回しにした結果、
現場で困った経験を残した実践ログです。
エラーは例外ではなく、
前提として扱うべきもの だと感じました。
コメント