チームが幸せになるカスタムエラーのススメ

Transcript

1. チームが幸せになるカスタムエラーのススメ Asakusa.go #5 2025. 05. 21
2. 01　自己紹介 02　背景 03　改善策：カスタムエラーの導入 04　導入してみた結果 05　まとめ 目次 Index
3. 自己紹介 Self Introduction 01
4. 4 自己紹介 氏名：中舘 澪男（@nakadate00） 生息：大田区蒲田　→　練馬区 趣味：京都観光・音楽ライブ 経歴：武蔵野大学データサイエンス学部 　　　→　株式会社BuySell Technologes 24新卒 技術：Go・Python・TypeScript(Hono)・Unity C#
5. 5 プロダクト群「バイセルリユースプラットフォーム Cosmos」の開発が進行中 Cosmosを活用して、バイセルグループ全体での業務効率改善や データドリブン経営の深化を目指しています。 リユースプラットフォーム Cosmos 自社開発のリユース特化業務基幹システムでありサービス群の集合体 買取申込 買取・査定 在庫管理 販売 多様なチャネルで収益最大化 CRM -顧客対応- 買取種別に応じた最適なシステム構築 Visit -訪問買取 - Store -店舗買取 - Promas -商材マスタ - Appraisal -専門査定 - Stock -在庫管理 - EXS -販売管理 - Core -会員管理- Portal -データ利用- Pocket -データ基盤- 買取 専門チームによる真贋・査定と連携 査定 申込 効率的な顧客対応 在庫 在庫管理の最適・効率化 販売 データ 各事業プロセスにある データを一元管理 ：基幹システム
6. 突然ですが、クライアントへのエラーはどんなものを返していますか？
7. 自分たちはGoのフレームワークである、echoの標準エラー を返していました Error Handling | Echo: https://echo.labstack.com/docs/error-handling
8. 自分たちはGoのフレームワークである、echoの標準エラー を返していました Error Handling | Echo: https://echo.labstack.com/docs/error-handling →　この方法だと辛い事象が起きたので、カスタムエラーを導入 した話
9. 背景 Background 02
10. 10 既存の実装だとFE側のエラーハンドリングが辛かった その文字がエラーメッセージに含まれていたらユーザには専用のメッセージを返すという条件分岐 BEからどんなエラーメッセージが返ってくるかをあらかじめ定義
11. 11 既存の実装だとFE側のエラーハンドリングが辛かった FEが各APIのメッセージを元に、ユーザに表示すべきエラーメッセージを出し分けていた • APIのエラーメッセージを予め調査する必要がある • BEでエラーメッセージを少しでも変えたら壊れる 新規アプリケーションの開発では以下の要件を満たす改善をしたい という話になった • APIのエラー時のレスポンスを予測しやすくする • ユーザに適切なメッセージを表示したい
12. 改善策：カスタムエラーの導入 Improvement: Custom Error 03
13. 13 サードパーティ・ライブラリの技術検証 • 例 ◦ cockroachdb/errors：スタックトレースやラップ情報を簡潔に付加できる ◦ morikuni/failure：コンテキストや原因情報を柔軟に付加できる ◦ etc… 結論：要件に対して、 too muchだった…。 それだったら、「Type付きの独自エラー」 を設計すれば良いのでは！？
14. 14 カスタムエラーの定義 echoの標準エラーとの違い • Typeを指定する • ステータスコードは指定しない ※指定するTypeは、アプリケーション 　内部でのエラーの判別に使う
15. 15 カスタムエラーのハンドリング APIのhandler層で、Typeによってクライアントに返 すエラーをハンドリングする （例） アプリケーション内部で、Typeが UserDataRetrievalErrorのエラーが発生 クライアントには • ステータスコード： 403 • Message：設定したメッセージ • Type：ForbiddenError というecho.NewHTTPErrorとして返す
16. 導入してみた結果 Results 04
17. 17 カスタムエラーだと FE側のエラーハンドリングが楽になった FEがエラーメッセージを意識する必要がなくなり、 Typeによる出し分けが可能になった
18. 18 カスタムエラー導入はまだまだ改善の余地あり • 新規アプリケーションの MVPだとそこまでTypeによる出し分けが必要ではなかった …。 ◦ ユーザへの適切なメッセージを表示するための基盤にはなっている • echoの標準エラーからの移行のために一時的な回避策を入れる必要があった …。 ◦ ハンドリング漏れで、panic errorになったり、全てInternal Server Errorになったり
19. まとめ Conclusion 05
20. 20 まとめ • カスタムエラー導入によって、 FE側での辛いハードコーディングが減った ◦ 今までFE側に苦労をかけてしまっていた…󰢛 ◦ チームに適したエラーをFE・BEで認識合わせることが大事 • 皆さんのエラーハンドリング手法についても聞いてみたいです！！ ◦ こうすればもっと良くなりそうとか ◦ うちのチームではこうしているとか
21. ご清聴ありがとうございました！
22. 22 付録：ステータスコードだけではエラーパターンを識別しきれないケース 例：同じステータスコードでも、エラー内容次第で出し分けたい時がある