web-dev-qa-db-ja.com

Nestサービスレイヤーでのエラー処理

REST API with NestJs を作成したいのですが、後でGraphQLを別のトップレベルレイヤーとして追加したいと思います。そのため、最初に基本レイヤーを用意しますコントローラ、サービス、およびTypeORMリポジトリ。IDでユーザーのユーザー名を更新するとします。コントローラーのルートは

PATCH /users/:id/username

サービスまたはリポジトリ層で2つの問題が発生する可能性があります。

  • ユーザーIDが存在しない可能性があります
  • ユーザー名はすでに存在します

この操作の基本的な流れは

  • IDでユーザーを取得する
  • ユーザーが存在しない場合のエラー処理
  • ユーザー名がすでに存在するかどうかを確認します
  • ユーザー名がすでに存在する場合のエラー処理
  • ユーザーのユーザー名を更新する

これらのエラーをどのように処理すべきかを考えています。この概念に基づいてすぐに例外をスローすることができました

https://en.wikipedia.org/wiki/Fail-fast

NestJsには、すぐに使える例外がいくつかあります

https://docs.nestjs.com/exception-filters#built-in-http-exceptions

問題は、サービスレイヤーでHTTP例外をスローするべきではないと思うことです。それらは私のコントローラーロジックでスローする必要があります。では、これらのエラーの一般的なアプローチは何ですか？

  • 更新されたユーザーの代わりにundefinedを返すだけですか？コントローラーは、どの部分が失敗したのかを知りません。
  • Errorを拡張する独自の例外を作成してスローする必要がありますか？
  • 事実のため、関数の戻り値の型が<User | NotFoundError | ConflictError>？
exceptionserror-handlingtypescriptonion-architecture
4
hrp8sfH4xQ4

サービス層でHTTP固有の例外をスローするべきではないと言うのは正しいです。サービス層には、httpに関する知識は必要ありません。

ほとんどのサーバーフレームワークには、トップレベルの例外ハンドラーとエラー処理ミドルウェアがあります。その最上位の例外ハンドラーは、コードで処理されない例外をキャッチし、500内部サーバーエラーを返す可能性があります。

通常、それをカスタマイズして、それがこの言語レベルの例外である場合は、このhttp応答を使用して大丈夫と言うことができます。 （System.Collections.Generic）KeyNotFoundExceptionをスローすると、asp.netの例のように、使用しているフレームワークがわからないため、トップレベルで404を返します。これは完全ではありませんが、二。

ここを見てください： https://docs.nestjs.com/exception-filters

3
Martin K