4

この質問に関するご意見をお寄せいただきありがとうございます。Jon Skeet が言ったように、Create() メソッドに例外をスローさせることにしました。より大きなアプリケーション向け。

そこで、次のコードを使用してクラスのインスタンスを作成します。

try
{
    SmartForms smartForms = SmartForms.Create("ball");
    smartForms.Show();
}
catch (CannotInstantiateException ex)
{
    Console.WriteLine("Item could not be instantiated: {0}", ex.Message);
}

カスタム例外:

using System;

namespace TestFactory234.Exceptions
{
    class CannotInstantiateException : Exception
    {

    }
}

どの例外クラスを使用するかを知るにはどうすればよいですか?

上記の例では、「すべてのシステム例外」のリストを取得する場所がわからないため、または「オブジェクトをインスタンス化できない」ためのリストがまだあるかどうか、または他の意味があるかどうか、独自の例外を作成しました。私にとって例外タイプを選択することは、常にそのような恣意的なプロセスのように思われるため、独自の例外タイプを作成することが一般的には最良のアイデアのようです。

または、例外について何か不足していますか? どの例外タイプを使用するかを決定する際に、他にどのような影響がありますか?

4

6 に答える 6

5

オブジェクトを作成できない理由が Create の引数が無効だった場合は、おそらくArgumentException. ArgumentExceptionただし、その種の例外を他のユーザーとは別に処理できるようにしたい場合は、から派生した独自のクラスをいつでも作成できます。（よろしいですか？）

于 2009-06-10T13:58:50.690 に答える
3

カスタム例外を作成する理由 カスタム例外を使用する理由とタイミングについて詳しく説明しています。

于 2009-06-10T14:00:19.033 に答える
2

特定の例外的なケースが発生したことをキャッチして知ることができると便利な場合は、新しい型を作成します。一般的なIO例外ではなく、ファイルが見つからなかったことを知っておくと便利ですか?.

于 2009-06-10T13:57:36.043 に答える
2

この件に関して、興味深いと思われるブログ投稿全体を書きました

要約すると、誰かがその型をキャッチして操作することを実際に期待しない限り、カスタム例外クラスを作成しないでください。

于 2009-06-10T14:02:02.040 に答える
0

既存の例外を見つけるには、ヘルプ ファイルが適していると思います。クラスのヘルプをException参照すると、概要ページに派生クラスのリストが表示されるはずです。

(から派生したException) 新しいものを作成するか、既存のものから継承するかを決定する方法は、例外の意味によって異なります。

Jon が言うように、コードがメソッドの引数に対して何らかの検証をCreate行う場合、派生した例外を作成することができますArgumentException(たとえばArgumentNonExistentEntityException、指定された ID が存在しない場合は、口いっぱいですが)。

作成している例外が、既存の例外からその意味を概念的に「継承」しない場合は、恥ずかしがらずにライブラリ用に新しい例外を作成してください。

于 2009-06-10T14:03:38.450 に答える
0

カスタム例外タイプを作成して、コンテキスト情報または意味をエラーに提供します。それ以外の場合は、ランタイムで生成された例外タイプに依存します。たとえば、System.DivideByZero 例外のような例外は、アプリケーションで一番上にバブルアップした場合、明らかではない場合があります。代わりに、上記の「DivideByZero」エラーに加えて、より多くのコンテキスト情報を提供するカスタム例外を作成できます。

実行時に生成されるさまざまな例外については、MSDN のシステム名前空間を参照してください。例外はネイティブ コードやサード パーティのライブラリからも生成される可能性があるため、これは完全なリストではありません。

于 2009-06-10T14:14:09.223 に答える