raiseをやめて得たもの、失ったもの

Transcript

2. raise をやめて得たもの、失ったもの PyCon JP 2026
3. ⾃⼰紹介 ⽒名 加藤雅也 経歴 2024/04/01 〜 Recustomer株式会社 普段はバックエンド開発に従事 Python歴：5年程度
4. 本セッションについて 対象 Python の Web アプリケーションの開発をしている⼈ ⽬的 失敗を値で返す、という選択肢があるということを知って欲しい 本セッションで話さないこと Python の基本⽂法 Rust など他⾔語の詳細
5. ⽬次 1 なんで raise をやめたの？ 2 じゃあどうするのか 3 Result って何、どう書く 4 raise をやめて得たもの 5 raise をやめて失ったもの 6 実際 raise やめてよかったの？
6. ⽬次 1 なんで raise をやめたの？ 2 じゃあどうするのか 3 Result って何、どう書く 4 raise をやめて得たもの 5 raise をやめて失ったもの 6 実際 raise やめてよかったの？
7. 遡ること2024年、本番リリース直後の状況 あれは2年前
8. 遡ること2024年、本番リリース直後の状況 エラー通知に 翻弄される毎⽇
9. 遡ること2024年、本番リリース直後の状況 監視システムからの通知は 実に２００件/週を超えていた
10. 遡ること2024年、本番リリース直後の状況 そのほとんどは？
11. 遡ること2024年、本番リリース直後の状況 例外捕捉失敗 これに悩まされ続けていた
12. raise された例外は、どこで catch すべき？ ? ? ? バッチ API ? Webhook ? 関数 ? 関数 関数 ? 関数 ? 関数 ? 関数 ? 関数 raise ! 伝播しうる経路は、呼び出し経路の数だけある（この図で 10 通り） 正しい受け止め場所はコードのどこにも書いていない 全経路を人間が覚えているしかない
13. エラー通知！ 全経路を守り続けることでしか防げない バッチ API except ✓ 関数 except ✓ 関数 関数 Webhook except ✓ 関数 関数 except なし 関数 関数 raise ! except を書いた経路は止まる。でも、 10 経路のうち 1 つ漏れただけで素通り 呼び出し元が増えるたび、覚えることが増える防御は、いつか破れる
14. 遡ること2024年、本番リリース直後の状況 例外ってそもそも 捕捉する必要があるときって あるの？
15. "重複エラー "は、成功である 確認メールを送る 注文を作成 IntegrityError: duplicate key 冪等なリトライなら “既に完了 ” ＝ 成功 ✓ except IntegrityError: pass # 黙殺？ 正常？ 区別がつかない 何もせず ③ へ進んで いい“エラー” 例外の型名は「成功かもしれない」を運べない。 通知に混ざれば、ただのエラーに見える 処理の途中には、 “エラーの顔をした成功 ” がある それを分類できるのは文脈だけで、型名ではない
16. 例外だけど業務的に例外として扱いたくないもの 事象 正体 してほしいこと 実は成功 何もせず続行（さっきの話） 起きるのが普通の業務 ユーザーに伝えるだけ。通知は不要 429 Rate Limit・タイムアウト・ LLM 混雑 一時的。待てば直る リトライする（毎回通知しないでほしい） LLM のトークン上限超過・入力が大きすぎる 何度やっても直らない リトライしない。入力・設計を直す 本物のバグ すぐ通知してほしい。すぐ直す 重複エラー（冪等リトライの 2 回目） 在庫切れ・クーポン期限切れ NoneType・KeyError・契約違反 扱いは 5 通りあるのに、例外はぜんぶ同じ “赤い通知 ”の顔で飛んでくる 分類は、受け取った人間に丸投げされる
17. このシグネチャ、何で失敗する？ def create_order(cart: Cart) -> OrderResponse: ...
18. このシグネチャ、何で失敗する？ def create_order(cart: Cart) -> OrderResponse: ... 読まないと分からない 在庫が切れているのかもしれないし、決済が通らなかったのかも、 例外は型に出てこないので、シグネチャからは何もわからない
19. 抜け漏れを自動で見つける術がない Python の typing には「raise を表す記法」が無い 何を投げるかはシグネチャの外。 どこに except が要るかを、 mypy も linter も判定できない 型に現れない以上、静的検査は抜け漏れを見つけられない 人間の注意力とレビューだけ 通知が来て初めて気づく 型に無い失敗は、 CI で守れない raise をやめたくなったきっかけ
20. ⽬次 1 なんで raise をやめたの？ 2 じゃあどうするのか？ 3 Result って何、どう書く 4 raise をやめて得たもの 5 raise をやめて失ったもの 6 実際 raise やめてよかったの？
21. そもそもPython の失敗の扱いは？ ✓ 失敗の道具は例外だけ。しかも⾮検査 C の errno 的な戻り値⽂化も、Java の検査例外も無い。何を raise するかは型検査の外 ✓ EAFP。Pythonの設計思想によるもの EAFP、「認可をとるより許しを請う⽅が容易」。公式ドキュメントの⽤語集に載っている設計思想
22. 他の⾔語は失敗をどう表してきたか C Java Go Rust 戻り値と errno 検査例外 (T, error) の多値 Result<T, E> 失敗はただの整数。無視 できるし、 型からは何も分からない 投げる例外をシグネチャ に書かせた。 例外は無い。失敗は値で 返す。 ただし、両⽅⼊りうる 例外は無い。失敗は値で 返す。 ⽚⽅だけ⼊る。match で 網羅する 新しい⾔語ほど、失敗は値で返す⽅に寄っている。Go と Rust の違いは、その値の形
23. 直積。Go の (T, error) は、両⽅⼊りうる 直積: (T, error) 値とエラーの全部の組み合わせが、型の上では存在する。複数値返すと⾔う点でPython似 order, err := CreateOrder(cart) // (Order, nil) OK
24. 直積。Go の (T, error) は、両⽅⼊りうる 直積: (T, error) 値とエラーの全部の組み合わせが、型の上では存在する。複数値返すと⾔う点でPython似 order, err := CreateOrder(cart) // (Order, nil) OK // (nil, err) 失敗
25. 直積。Go の (T, error) は、両⽅⼊りうる 直積: (T, error) 値とエラーの全部の組み合わせが、型の上では存在する。複数値返すと⾔う点でPython似 order, err := CreateOrder(cart) // (Order, nil) OK // (nil, err) 失敗 // (Order, err) ← 型の上では作れてしまう 両⽅ある、両⽅ない、というおかしな状態を型が⽌めてくれない
26. 直和。Rust の Result<T, E> は、⽚⽅だけ 直和: Result<T, E> Ok(T) か Err(E) の、どちらか⼀⽅だけ match create_order(cart) { Ok(order) => ..., Err(OutOfStock) => ..., Err(PaymentDeclined) => ..., } // 分岐が漏れるとコンパイルエラー おかしな状態が型の定義から消える。分岐の漏れもコンパイラが⾒つけてくれる これPythonでも書けないの？？Python でこれを書ける道具が揃ったのが、3.10 以降
27. Python が直和を書ける⾔語になった 3.10 X | Y と match ⽂ 3.11 typing.assert_never 3.12 PEP 695 の型パラメータ構⽂ エラーの型を union で並べて、match で分岐できるようになった match の漏れを mypy や pyright が⾒つけてくれる class Result[T, E]: と書ける。ジェネリクスがだいぶ読みやすくなった ずっと例外の⽂化 (EAFP) の⾔語だったけれど、いまは直和を型で書いて、漏れを CI で⾒つ けられる
28. 2024 年 8 ⽉ 、社内の議論ページ「例外について」
29. 落ちたら困る現場で⾝についた考え⽅ 型検査で潰せるものは、型検査で潰す。 動かして初めて分かる失敗をなるべく減らす CTO は前職でロボットのコードを書いていた⼈で、動いてからバグが出ると物理的な事故に なる世界にいた。 そこで⾝についた考え⽅を、そのまま Web にも持ち込んだ。⽌まると顧客の業務が⽌ま る、という意味では同じなので
30. raise は原則やめる。 Result 型で表現する。
31. ⽬次 1 なんで raise をやめたの？ 2 じゃあどうするのか 3 Result って何、どう書く 4 raise をやめて得たもの 5 raise をやめて失ったもの 6 実際 raise やめてよかったの？
32. Result 型とは Result<T, E> のイメージ Ok(値) 成功時の結果を包む 成功か失敗か、 どちらか⼀⽅だけが⼊る箱。 どちらか⼀⽅のみ 成功のときは成功の値のみを、 Err(理由) 失敗のときは失敗の値のみを取得できる 失敗時のエラー内容を包む
33. うちの Result 型はこんな形（簡易版） @dataclass(frozen=True) class AnyError: # 全エラーの基底。 error_message: str class Result[T, E: AnyError]: is_ok: bool is_err: bool ok: T # 成功時のみ触れる err: E # 失敗時のみ触れる def ok(value: T) -> Result[T, E]: ... # 成功を作成する def err(error: E) -> Result[T, E]: … # エラーを作成する def expected(self, msg: str) -> T: ... # Ok と⾔い切る。Err なら AssertionError で⽌める # デコレーター 拾い忘れた例外をエラーに変換する def shield_exception(): ...
34. うちの Result 型はこんな形（簡易版） @dataclass(frozen=True) class AnyError: # 全エラーの基底。 error_message: str class Result[T, E: AnyError]: is_ok: bool # okがどうかを返却する is_err: bool # errかどうかを返却する ok: T # 成功時のみ触れる err: E # 失敗時のみ触れる def ok(value: T) -> Result[T, E]: ... # 成功を作成する def err(error: E) -> Result[T, E]: … # エラーを作成する def expected(self, msg: str) -> T: ... # Ok と⾔い切る。Err なら AssertionError で⽌める # デコレーター 拾い忘れた例外をエラーに変換する def shield_exception(): ...
35. うちの Result 型はこんな形（簡易版） @dataclass(frozen=True) class AnyError: # 全エラーの基底。 error_message: str class Result[T, E: AnyError]: is_ok: bool # okがどうかを返却する is_err: bool # errかどうかを返却する ok: T # 成功時のみ触れる err: E # 失敗時のみ触れる def ok(value: T) -> Result[T, E]: ... # 成功を作成する def err(error: E) -> Result[T, E]: … # エラーを作成する def expected(self, msg: str) -> T: ... # Ok と⾔い切る。Err なら AssertionError で⽌める # デコレーター 拾い忘れた例外をエラーに変換する def shield_exception(): ...
36. うちの Result 型はこんな形（簡易版） @dataclass(frozen=True) class AnyError: # 全エラーの基底。 error_message: str class Result[T, E: AnyError]: is_ok: bool # okがどうかを返却する is_err: bool # errかどうかを返却する ok: T # 成功時のみ触れる err: E # 失敗時のみ触れる def ok(value: T) -> Result[T, E]: ... # 成功を作成する def err(error: E) -> Result[T, E]: … # エラーを作成する def expected(self, msg: str) -> T: ... # Ok と⾔い切る。Err なら AssertionError で⽌める # デコレーター 拾い忘れた例外をエラーに変換する def shield_exception(): ...
37. 実際どんな⾵に書いているのか # ① 作る def create_order(cart) -> Result[Order, OutOfStock | PaymentDeclined]: if not stock.has(cart.items): return Result.err(OutOfStock(...)) # 失敗は Result.err ... return Result.ok(order) # 成功は Result.ok
38. 実際どんな⾵に書いているのか # ② 受ける result = create_order(cart) if result.is_err: match result.err: case OutOfStock(): ... case PaymentDeclined(): ... case _: assert_never(result.err) # 漏れは mypy が⾒つける order = result.ok
39. 実際どんな⾵に書いているのか # ② 受ける result = create_order(cart) if result.is_err: match result.err: case OutOfStock(): ... case PaymentDeclined(): ... case _: assert_never(result.err) # 漏れは mypy が⾒つける order = result.ok
40. いちばん効いたのは網羅性チェック def create_order(cart) -> Result[Order,OutOfStock | PaymentDeclined]: ... result = create_order(cart) if result.is_err: match result.err: case OutOfStock(): ... case PaymentDeclined(): ... case _: assert_never(result.err) 1 種類増やしたら、何が 起きる？
41. いちばん効いたのは網羅性チェック def create_order(cart) -> Result[Order, OutOfStock | PaymentDeclined | CouponExpired]: ... エラーを 1 種類増やすと result = create_order(cart) if result.is_err: match result.err: err_value を match している場所すべてで CI が落ちる case OutOfStock(): ... case PaymentDeclined(): ... case _: assert_never(result.err) $ mypy . error: Argument 1 to "assert_never" has incompatible type "CouponExpired"; expected "Never" try/except ではこうならな い。増えた失敗を except は 気づかずに飲み込み続ける
42. Result の世界の中は、これで書ける ✅ 何で失敗するかはシグネチャに並ぶ 関数のシグネチャから返却する型がわかる ✅ エラーの型を増やせば mypy が落ちる match している場所すべてで CI が落ちる。⼈が探して回らなくていい
43. Result の世界の中は、これで書ける ✅ 何で失敗するかはシグネチャに並ぶ 関数のシグネチャから返却する型がわかる ✅ エラーの型を増やせば mypy が落ちる match している場所すべてで CI が落ちる。⼈が探して回らなくていい この２つの恩恵を享受できることが最⼤のメリット
44. ⽬次 1 なんで raise をやめたの？ 2 じゃあどうするのか 3 Result って何、どう書く 4 raise をやめて得たもの 5 raise をやめて失ったもの 6 実際 raise やめてよかったの？
45. シグネチャが仕様書になる。AI時代にも効果的 ✅ ✅ 何で失敗するかを知るのに、関数の中⾝を開かなくていい コンテキストウィンドウは有限。読まなくていいものが増えるほど、本題に使える docstring と違って、シグネチャは実装とずれない 更新忘れのdocstring を信じて書く、が起きない。型は実装が変われば⼀緒に変わる ✅ 対応漏れは mypy が落とすので、エージェントが⾃分で直す 拾い忘れがないかを⼈が⽬で追う仕事は、CI に移った ✅ レビューの論点が変わった 「例外拾った？」から「この失敗、業務ではどう扱う？」に
46. ⽬次 1 なんで raise をやめたの？ 2 じゃあどうするのか 3 Result って何、どう書く 4 raise をやめて得たもの 5 raise をやめて失ったもの 6 実際 raise やめてよかったの？
47. 現実問題、周りは例外だらけ 標準ライブラリ raise Django ORM raise あなたのアプリ 中は Result だけにしたい。 でも呼ぶ相⼿は全部 raise してくる。 httpx / boto3 raise raise をResultに変換してあげる必要があ DBドライバ raise 外部SDK raise ります 境⽬
48. 境界は、外部を呼ぶ関数の中 R es ul t ra is e アダプター ユースケース ドメイン アダプターは例外を受けたら 必ずResultに変換してから 中に渡す
49. 外部を使う関数はこう書く @Result.shield_exception def fetch_product(product_id) -> Result[Product, ProductNotFound | FatalError]: try: row = ProductModel.objects.get(pk=product_id) # 外 (Django ORM) はここだけ except ProductModel.DoesNotExist: return Result.err(ProductNotFound(product_id)) return Result.ok(convert(row)) ✅ ✅ 外部を触る関数は例外を受けて、Resultを返す except はここで書き切って、Err に変える。ユースケースやドメインに try/except は書かない FatalError が並んでいるのは、想定外の例外の受け⽫ DoesNotExist 以外が⾶んできたらどうするか。
50. shield_exception。変換し忘れた例外を拾う def shield_exception(func): def wrapper(*args, **kwargs) -> Result[R, F | FatalError]: try: return func(*args, **kwargs) except Exception as err: _logger.error(..., trace=stack_trace) return Result.err(FatalError.from_exception(err)) return wrapper 戻り値の型が F | FatalError に増える。呼び出し側は FatalError も match するしかない
51. boto3 はこう包んでいる class S3Client: @Result.shield_exception() def download_text(self, bucket, key) -> Result[str, FatalError]: obj = self._s3.get_object(Bucket=bucket, Key=key) return Result.ok(obj["Body"].read().decode()) ✅ ✅ 外部 SDK は raise してくる前提。包む側はデコレータ 1 つ ClientError は業務エラーではなく想定外。except は書かず shield_exception に任せる (中⾝は次で) 使う側は Result しか⾒ない SQS も DynamoDB も ECS も同じ形
52. リトライも、例外ではなく Err を⾒てやる fetch = Retrier( fetch_order, # Result を返す関数 max_retries=3, retry_condition=lambda e: isinstance(e, Timeout), # どの Err なら再試⾏するか ) result = fetch(order_id) ✅ # is_err ならバックオフして再試⾏ 例外を待つ retry デコレータは、値で返る失敗を⾒ない Err は例外ではないので、tenacity のようなものは素通しする。なので Result を⾒てリトライする Retrier を⾃前で持っている ✅ どの Err なら再試⾏するかを、エラー型ごとに決められる
53. このコード、何が起きる？ with transaction.atomic(): reserve_stock(order) result = charge_payment(order) # この関数が失敗 if result.is_err: return result 課⾦が失敗した。 在庫の引当は どうなる？
54. atomic() はロールバックしない with transaction.atomic(): reserve_stock(order) result = charge_payment(order) if result.is_err: return result # ← 在庫はコミットされる！ Err は例外ではない。 ただの return。 Django からは成功に⾒え るので そのままコミットする atomic() は __exit__ に例外が来たときだけロールバックする。 値で返る失敗は⾒えないし、ブロックの中から rollback を呼ぶ⼿段もない
55. 対処。インフラの中では例外に合わせる やったこと。Err を専⽤の例外に包んで raise し、atomic の外で Err に戻す def transaction_with_result(cb): try: with transaction.atomic(): if (r := cb()).is_err: raise _CustomError(r.err) # rollback 発⽕ return r except _CustomError as e: return Result.new(e.inner) # 外で Err に戻す
56. 境界のルール 外部を呼ぶ関数の中で except して Err に変える 境⽬はそこだけ。ユースケース、ドメイン の中に try/except を書いたら負け 変換し忘れは shield_exception が FatalError にして型に乗せる 想定外の失敗が黙って消える経路が、そもそも無い
57. コードは、確実に⻑くなる 例外なら 5 ⾏ Result だと 11 ⾏ def create_order(cart) -> Order: reservation = reserve_stock(cart.items) price = apply_coupon(cart.coupon) charge_payment(cart, price) return Order(...) def create_order(cart) -> Result[Order, ...]: r1 = reserve_stock(cart.items) if r1.is_err: return Result.err(r1.err) r2 = apply_coupon(cart.coupon) if r2.is_err: return Result.err(r2.err) r3 = charge_payment(cart, r2.ok) if r3.is_err: return Result.err(r3.err) return Result.ok(Order(...)) Rust の ? にあたる糖⾐が Python には無い。受けるたびに 2 ⾏ずつ増える LBYLの思想になるので、Pythonの設計思想から逸れる
58. まだ払い続けているもの Result の触り⽅を間違えても、 mypyでは防げない 現在の設計だとErr のまま ok を触ることをmypyで → は防げていない。レビュー頼み（RustのResultだと ここまで制限できる） 学習コスト。Python らしくない書 規約と⼿本コード。AI は規約より既存コードを真似 → るので、最初は⼈が書く き⽅を、⼈にも AI にも教える それでも本番のアプリでは払う価値があった？
59. ⽬次 1 なんで raise をやめたの？ 2 じゃあどうするのか 3 Result って何、どう書く 4 raise をやめて得たもの 5 raise をやめて失ったもの 6 実際 raise やめてよかったの？
60. 現在の状況 ２００件/週 ７件/週
61. 実際 raise やめてよかったの？ 想定外のエラー減った エラー対応が楽になった 関数の理解が楽になった
62. 通知の中⾝も変わった 導⼊前（例外） 導⼊後（Result） AttributeError FatalError(error_message='...') KeyError InfrastructuralError(...) ValueError / TypeError 「メール送信に失敗しました」 InternalServerError 「外部サービス への決済失敗」 Exception (素の Exception) DhlApiError(...) ValidationError AssertionError (契約違反で⽌めた) 捕捉に失敗した例外ではなく、Resultのエラーが通知の中⼼になっている
63. 効く場所、割に合わない場所 効く 割に合わないかもしれない 本番で動いているWebアプリ 再実⾏すればいいバッチや 取りこぼしがそのまま事故になった 使い捨てのスクリプトは り、エラー対応の時間が取られたり 境界を作る⼿間のほうが⼤きい
64. 実際 raise やめてよかったの？ リファクタリング⼤変じゃない？？
65. 実際 raise やめてよかったの？ リファクタリング⼤変じゃない？？ ⼤変
66. 明⽇から試すなら 新しいモジュール 1 つから １つの関数だけResultにするというのも効果があると思い ます
67. まとめ 失敗は raise ではなく、Result で返す 何で失敗するかがシグネチャに並び、型が想定外のバグを⾒つける 例外との境界を作成するのは⼤変 境界は外を呼ぶ関数の中だけにするようにリファクタリングを進めていくこ とは⼤変
68. ご清聴ありがとうございました