課題

• DDD アプリケーション開発の中で、エラーをハンドリングしたい。
• 理想的には、layer を跨ぐごとに呼び出し元の意図に応じて正常系とするか、その層のエラーに変換したい
• しかし、現実にそれをしようとすると、error 処理の度に10行くらいのエラーハンドリングコードが書かれることになる。

前提

• Go で DDD アプリケーションを書いている
• failure を使って stacktrace を付与している

なぜエラーハンドリングしたいか

• エラーの内容によってその後の処理を分けたい
• 適切にハンドリングできないと、ユーザーが連打する

エラーの種類

• 未知のエラー
• 既知のエラー

それぞれについて、どういう挙動にしたいか、ユーザーに何を期待するか、開発者がどうすべきか
を考える

挙動：
ユーザーに期待すること：
開発者がどうすべきか：

未知のエラー

挙動：サーバー起因のエラーとして、処理を止めたい。
ユーザーに期待すること：しばらく時間を空けて試してもらうか、サポートに問い合わせるかしてほしい
開発者に期待すること：エラーとして通知を受け取り、既知のエラーとして扱う

既知のエラー

起こりうるエラー

例えば、「ユーザーが入力した名前がすでに存在していた」

挙動：ユーザー起因のエラーとして、処理をそこで止めたい。ユーザーに、名前が重複している旨を伝えるようなエラーを返す
ユーザーに期待すること：別の名前を使って再度リクエストする
開発者がどうすべきか：通知も受け取らない。何もしない。

別の例として、「バッチ処理の結果を見たいのでユーザーがページを表示しようとするが、まだ処理中」

挙動：
ユーザーに期待すること：
開発者がどうすべきか：

起こらないと思ってるけど、コード上存在するエラー

例えば、「context から UserID を取得しようとして、取得できなかった」
これは、前提として置いてる処理が行われていなかったエラー。

挙動： サーバー起因のエラーとして、処理を止めたい。
ユーザーに期待すること：しばらく時間を空けて試してもらうか、サポートに問い合わせるかしてほしい
開発者がどうすべきか：エラーとして通知を受け取り、想定外のエラーとして原因を究明して再発しないように対処する。

例えば、「DB の接続が切れた」「AWSの障害で接続エラー」

起動時であればリトライする

AWS の障害は途中で起きるので、サービスを止める？

以下のようなエラーの種類を思いつく

• システム（実装）上は予期していないエラー。調査のために幾つかの情報を付与して出力したい
• ユーザー起因のエラー。エラー通知も不要だし、対応も不要。ただし、数をカウントするくらいはできたほうが良いかも
• 知らないエラー。外部システムに依存していて、何か起こるかもしれないが、よく知らないエラー。一度処理は止め、ユーザーには待っていただく。エラーを通知して、できるだけ早く対応する

アプリケーションロジックの関わらない Invalid argument を上記ではカバーできないので、短期的な使用を許して追加で定義する