Exceptionは適切にThrowする必要がある。 この記事は完成していません。
ここから学んでいく
今わかっていることを書いていく。
以下のリンクは見つけただけで読んでない。
- Exception Handling Middleware In .NET Core Web API
- Handle errors in ASP.NET Core web APIs
- Error handling and validation architecture in .NET Core
- .NET 6.0 - Global Error Handler Tutorial with Example
- Error Handling and Validation Architecture in .NET Core
読んでみて
Microsoft先生のドキュメントを読み込む。 ど頭に”例外処理機能は、プログラムの実行時に発生する予期しない状況や例外的な状況を扱うのに役立ちます。成功しない可能性があるアクションを試行し、適切な場合はエラーを処理して、後からリソースをクリーンアップします。”と書いてあります。
エラーバリデーション vs 例外処理
- エラーバリデーション:
- エラーバリデーションは、主に入力データが期待されるフォーマットや条件を満たしているかどうかを確認するプロセスです。これは通常、エラーが発生する前に行われ、ユーザーに適切なフィードバックを提供することで、エラーを修正する機会を与えます。
- 例外処理:
- 例外処理は、プログラムの実行中に予期せぬエラーや問題が発生した場合に使用されます。例外は、通常、プログラムの正常な流れを中断し、エラーをキャッチして処理するメカニズムを提供します。
例外処理によるエラーハンドリングアーキテクチャについて
ユーザー入力のバリデーションがエラーであった場合に例外を投げ、ミドルウェアでキャッチしてレスポンスを返すアーキテクチャには、いくつかの利点と欠点
利点
- 集中化されたエラーハンドリング:
- エラーハンドリングのロジックを集中化し、アプリケーション全体で一貫したエラーレスポンスを提供できます。
- カスタマイズ可能なエラーレスポンス:
- エラーコード、エラーメッセージ、および他のレスポンスパラメータをカスタマイズし、ユーザーに適切なフィードバックを提供できます。
欠点
- パフォーマンスオーバーヘッド:
- 例外の投げとキャッチは、エラーコードを返すよりもコストがかかる可能性があります。
- エラートラッキングの困難:
- 大規模なアプリケーションでは、どこで例外が投げられ、どのミドルウェアがそれをキャッチするのかを追跡することが困難になる可能性があります。
結論
ExceptionはExceptionとするか、エラーハンドリングアーキテクチャとするか 結局、プロジェクトの方針や人それぞれである。
