以下のような検証とロジックでエラーを投げるのがベストプラクティスかどうかは不思議でした。私はコントローラの私のOnExceptionメソッドでこれらを捕まえて、JSONとしてAjax経由でクライアントに送り返しています。このような例外をスローしていますか？Validationの例外処理.NETのベストプラクティス
public void Update(EditTeacherModel model)
{
var entity = _teachersRepository.FindBy(model.Id);
if(entity == null)
throw new NatGeoNotFoundException("Teacher");
}
特別なクリーンな例外タイプを使用している限り、これが問題になる理由はありません。例外は、複数のネストされた呼び出しスタックフレームから抜け出す便利な方法です。
例外は、CLRでは非常にであることに注意してください。
例外は、コストです。カスタム/ビジネスエラーを処理するためのベストプラクティスは、適切なエラーコードを返すことです。ベストプラクティスを扱う
例外は、ここで説明されていますhttp://www.codeproject.com/Articles/9538/Exception-Handling-Best-Practices-in-NET
また、ここで議論されています：.NET Throwing Custom Exceptions
例外は高価です。私はそれらがあなたのアプリケーションの予期しない動作を意図していると信じています。
検証エラーは決して例外を投げるべきではないと私は思います。
これはあなたのリンクから来ました。無視してはいけないエラーの例外を使用する これには実際の例を使用します。人々がCrivo（私の製品）にアクセスできるようにAPIを開発する場合、まずログインメソッドを呼び出す必要があります。 Loginが失敗した場合、または呼び出されなかった場合、他のすべてのメソッド呼び出しは失敗します。失敗した場合は、単にfalseを返すのではなく、呼び出し側のプログラムが無視できないように、Loginメソッドから例外をスローすることを選択しました。 - –