例外処理

💡 主な例外型： ValueError（不正な値）、TypeError（型の不一致）、KeyError（辞書に存在しないキー）、IndexError（リスト範囲外）、FileNotFoundError（ファイルなし）、ZeroDivisionError（0除算）

💡 try/except の実行フロー：

try ブロックを実行
 ├─ 例外が発生しなかった → try ブロック全体を実行して次へ進む
 └─ 例外が発生した     → その行で中断
      ├─ 対応する except がある → except ブロックを実行して次へ進む
      └─ 対応する except がない → 例外が上位に伝播（プログラムが止まる）

💡 except の書き方バリエーション：

except ValueError:               # 単一の例外型を捕捉
except (ValueError, TypeError):  # 複数をまとめて捕捉（どちらでも同じ処理）
except ValueError as e:          # 例外オブジェクトを e に代入
except Exception as e:           # すべての例外を捕捉（最後の手段）
except:                          # 例外型不問（SystemExit も捕捉：非推奨）

except Exception as e: は「想定外のエラーが起きたらログを記録して終了する」 用途で最後のフォールバックとして使います。ただし乱用するとバグを隠す原因になるため注意が必要です。

💡 例外オブジェクト e から取れる情報：

try:
    value = int("N/A")
except ValueError as e:
    print(str(e))             # → invalid literal for int() with base 10: 'N/A'
    print(type(e).__name__)   # → ValueError
    print(e.args)             # → ("invalid literal for int() with base 10: 'N/A'",)

ログファイルにエラー詳細を記録したい場合は str(e) でメッセージ文字列を取得できます。

🐛 try に書きすぎると起きる問題：

# NG 問題のある書き方
try:
    value = int(user_input)     # ← 入力変換（ここの ValueError を捕まえたい）
    save_to_db(value)           # ← DB保存（ここの ValueError も同じ except に来てしまう！）
except ValueError:
    print("数値を入力してください")  # DB保存のバグでも「数値を入力して」と表示されてしまう

save_to_db() の内部でも ValueError が発生すると、 入力は正しかったのに「数値を入力してください」と表示されます。 本当の原因（DBエラー）は隠れてしまいます。

# OK else を使った書き方
try:
    value = int(user_input)     # ← ここだけを監視
except ValueError:
    print("数値を入力してください")  # int() のエラーだけを捕捉
else:
    save_to_db(value)           # try が成功したときだけ実行。ここの ValueError は上の except に吸収されない

else に書いた処理で例外が起きた場合は except をスルーして プログラムの外側へ伝播します。つまり「隠さず、そのままエラーを出す」動作になり、 バグの原因がすぐに分かります。

💡 try / except / else / finally の実行フロー：

💡 実際はwith文を使う： ファイルを with open(...) で開けば finally での手動クローズは不要です。with 文は内部的に __enter__ / __exit__ を使って自動クリーンアップを行います。finally はDB接続のクローズや一時ファイルの削除など、with 構文が使えない場面で真価を発揮します。

💡 finally が役立つ実用例：

• データベース接続の解放（conn.close() を必ず実行）
• ネットワークソケットのクローズ
• 処理の開始・終了ログの記録（成功・失敗にかかわらず処理完了を記録）
• 一時ファイルの削除（エラーで中断してもゴミファイルを残さない）
• プログレスバーのリセット（UI処理でエラー後も画面を正常状態に戻す）

💡 raise と try/except の役割分担：

• 関数の中（raise）：「この値はおかしい」と例外を投げるだけ。どう対処するかは関知しない
• 呼び出し元（try/except）：投げられた例外を受け取る。エラーメッセージを表示したり、デフォルト値を使うなど対処を決める

validate_age(-5) を呼び出す
  → 関数内で raise ValueError(...) が実行される
  → 例外が呼び出し元の try ブロックに伝わる
  → except ValueError as e: で受け取る  ← ここがなければプログラム停止

💡 raise（引数なし）— 例外を受け取りつつ上位に投げ直す：

except ブロック内で raise だけ書くと、受け取った例外をそのまま上位に再発生させます。 「エラーをログに記録したいが、例外を握りつぶさず呼び出し元にも伝えたい」場面で使います。

try:
    validate_age(-5)
except ValueError as e:
    print(f"[ログ] エラーを記録: {e}")  # ログだけ残して…
    raise                               # 例外を再び投げる → 呼び出し元にも伝わる

raise を書かずに except ブロックを終わらせると例外は握りつぶされ、呼び出し元はエラーが起きたことを知れません。意図的にエラーを無視するのでなければ、raise で伝播させるのが基本です。

💡 カスタム例外クラスの設計指針：

• クラス名は Error で終わる慣習（例: InvalidVitalError、DataValidationError）
• 適切な標準例外を継承する（入力値の不正 → ValueError、実行時の異常 → RuntimeError）
• シンプルな用途なら pass だけでクラスを作ればOK。__init__ は追加情報が必要なときだけ実装する
• PyTorchの RuntimeError: CUDA out of memory や ValueError: Expected input size なども同じ仕組みで定義されている