BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//pretalx.com//pyconjp2026//speaker//XLFNDE
BEGIN:VTIMEZONE
TZID:Asia/Tokyo
BEGIN:STANDARD
DTSTART:20250822T000000
TZNAME:JST
TZOFFSETFROM:+0900
TZOFFSETTO:+0900
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
SUMMARY:raiseをやめて得たもの、失ったもの - 加藤雅也
DTSTART;TZID=Asia/Tokyo:20260822T154500
DTEND;TZID=Asia/Tokyo:20260822T161500
DTSTAMP:20260818T075621Z
UID:pretalx-pyconjp2026-ATEELF@pretalx.com
DESCRIPTION:数年前、本番で動く Python のモノリポで「raise 
 は原則やめよう」と決めました。例外が前提の言語で
 の逆張りと分かったうえで2年間貫いた結果を報告しま
 す。\n\nraise の代わりに選んだのは、失敗を「直和型」
 で表すことです。社内では Result 型と呼びますが、Haskel
 l の Either、値の不在を表す Optional/Maybe も仲間で、「結
 果は値かエラーのどちらか一方」を型で示す発想です
 。対して Go の (value\, error) や例外は、両者を同時に返
 せる「直積型」です。\n\n得たものは明確です。シグネ
 チャだけで何で失敗するか分かり、try/except で例外を握
 りつぶす事故が減り、バグと業務エラーを型で分けた
 ことで、直すべきものだけが通知に上がるようになり
 ました。\n\n一方で失ったものもあります。標準も外部
 もライブラリは例外を投げるので、コードは例外と直
 和型の境界で暮らしています。共通エラー型 AppError を
 作ってかえって苦しみ、transaction.atomic() が err でロール
 バックしない罠にもはまりました。原則は現場の都合
 で何度も書き換わりました。\n\nバッチやデータ基盤な
 ら握りつぶして再実行でも回りますが、オンラインの
 実運用アプリでは取りこぼしが事故になります。だか
 らこそ型に乗せる価値が高い。効く場所と要る覚悟ま
 でお話しします。\n\n## このトークで話すこと\n- なぜ ra
 ise をやめたのか / 直和型(Result・Either・Optional)とは\n- 
 直和 vs 直積：例外・(value\, error)・null と何が違うか\n- 
 得たもの・失ったもの（握りつぶし減・バグと業務エ
 ラー分離 ⇔ 例外境界・共通エラー型・トランザクショ
 ンの罠）\n- まとめ：実運用アプリだからこそ効く理由
 と覚悟が要る場所
LOCATION:Dahlia 2
URL:https://pretalx.com/pyconjp2026/talk/ATEELF/
END:VEVENT
END:VCALENDAR