0

フォームにエラー メッセージを表示するために GUI レイヤーで使用DataAnnotationsしていますが、サービス レイヤーからの例外を処理する方法と、例外が発生した場合にユーザーに何を表示するかについていくつか質問があります。

サービス層と通信するには、リクエストとレスポンス クラスを使用します。例えば：

public class RegisterUserRequest
{
    public string Username { get; set; }
    public string Password { get; set; }
    public string Email { get; set; }
}

セッター メソッド内のリクエスト クラスで null をチェックする必要がありますか? または、サービスでこれを行う必要がありますか? ArgumentNullExceptionリクエスト セッター メソッドとレスポンス セッター メソッドの両方でこれを行い、パラメーターが null の場合はスローするのが理にかなっていると思います。

私のサービスクラスではInvalidOperationException、たとえばユーザー名またはパスワードが無効な場合にスローします。これはスローする正しい例外ですか?

私が持っているもう 1 つの質問は、すべての例外をキャッチする必要があるかどうかです。キャッチする場合、例外についてユーザーに何を伝えればよいでしょうか? たとえば、一部のプロパティが null の場合、ArgumentNullException. しかし、これについてユーザーに知らせる必要がありますか?

ユーザー名が無効な場合、InvalidOperationException. これは、少なくとも 3 文字か何かを使用する必要があることをユーザーに伝えるため、ユーザーに表示したいものです。

InvalidOperationExceptionからのエラーメッセージを使用してユーザーに表示し、「おっと、何か問題が発生しました」などの他の例外が発生したときに標準エラービューにリダイレクトする必要があると思います。

4

2 に答える 2

0

ユーザー名またはパスワードが無効な場合にスローするより適切な例外は、ArgumentExceptionだと思います。その例外タイプの説明では、引数が無効である場合を具体的にカバーしています。

ユーザーに例外を渡すことに関しては、サービスの内部動作を公開せずにエラーをユーザーに通知するようにしてください。そのため、「無効なユーザー名-少なくとも3文字である必要があります」というエラーを含む応答メッセージが表示されます。彼らに有用なフィードバックを与える。

詳細に伝えたくないエラーについては、自分でエラーメッセージをログに記録してから、エラーIDをユーザーに渡すことをお勧めします。例：「未処理のエラーが発生しました。エラーIDxxxを引用してサポートに連絡してください」。ただし、これは最後の手段としてのみ使用する必要があります。修正方法をユーザーに通知することをお勧めしますが、これは、クライアントに多くの情報を渡さずにすべてのエラーをキャッチするための適切な方法です。

于 2013-02-22T13:39:07.400 に答える
0

ユーザー名またはパスワードに正しいフォーマットを入力しないと、誰もエラーページにリダイレクトされたくないので、単純に DataAnnotations をもう一度使用します。

于 2013-02-22T13:36:44.650 に答える