引数の有効性をチェックするメソッドがある場合、から派生した独自のカスタム例外をスローしても大丈夫System.ArgumentExceptionですか？ArgumentExceptionから派生しSystem.SystemExceptionているため、アプリケーションがから派生する必要があるかどうかについて、矛盾するガイドラインが表示されているため、質問していますSystemException。（間接的でArgumentExceptionはありますが、から派生することは、から派生することと同じSystemExceptionです。）
ApplicationExceptionから派生するのではなく、代わりに例外から派生するというガイドラインがたくさんあります。私はそれに満足しています。私がよくわからないのは、SystemExceptionから派生しても大丈夫かどうかです。
から派生するべきではない場合SystemException、"invalid argument"例外クラスを何から派生させる必要がありますか？
例外処理のベスト プラクティスに関する MSDN ページには、
無効なパラメーターが渡された場合、ArgumentException または ArgumentException から派生したクラスをスローします。
だから私はそれが大丈夫だと言い、推奨さえします。
System.ArgumentException から派生させる利点の 1 つは、catch(System.ArgumentException)ブロックがカスタム例外タイプとSystem.ArgumentException. これはあなたが望むものかもしれませんし、そうでないかもしれません。
「無効な引数」の例外を派生させたいが、それ以上の意味がない場合はArgumentException、妥当な候補のように聞こえます。
ArgumentExceptionは、メソッドが呼び出され、渡された引数の少なくとも 1 つが呼び出されたメソッドのパラメーター仕様を満たしていない場合にスローされます。--MSDN
.Net の例外の背後にある元のアイデアは、基本クラス ライブラリ (システム アセンブリなど) の例外が派生した例外をスローし、BCL 例外とアプリケーション例外を区別System.Exceptionするためにすべてのカスタム例外が継承することを通知するというものでしたが、Microsoft はこれについて後戻りしました。System.ApplicationExceptionすべての例外が から継承することを提案しますSystem.Exception。
Exception私のアドバイスは、意味のあるフレームワークの最下位クラスから継承することです。
例外が、この引数に問題がある以外の特定の何かを意味する場合、たとえば、型がセマンティクスを例外に追加できる (と同じようArgumentNullExceptionにArgumentOutOfRangeException) 場合は、カスタムのものを作成します。そうでない場合はArgumentException、意味のある例外メッセージを使用して提供します。
ArgumentException プロパティを 100% 再利用し、追加機能を追加する場合は問題ありません。ただし、その名前だけを再利用するだけではダメです。