4

私はすでにこの質問に対する答えを探しており、次の提案を見つけました。

  1. 常に値が見つかることを期待している場合は、値が見つからない場合に例外をスローします。例外は、問題があったことを意味します。値が欠落しているか存在している可能性があり、両方がアプリケーション ロジックに対して有効な場合は、null を返します。
  2. 本当にエラーである場合にのみ、例外をスローします。オブジェクトが存在しないことが予期される動作である場合は、null を返します。

しかし、私の（非常にカジュアルな）ケースでそれらをどのように解釈する必要がありますか: 私の Web アプリコントローラーは、特定の ID を持つユーザーの詳細を表示する要求を受信して​​います。コントローラーはサービス層にユーザーを取得するように要求し、サービスはオブジェクトが見つかった場合はそれを返します。そうでない場合は、「デフォルト」の場所へのリダイレクトが発行されます。

誰かがリクエスト URL 内で無効なユーザー ID を渡した場合、どうすればよいですか? それを「予期される動作」と見なして null をコントローラーに返す必要がありますか、それとも「問題または予期しない動作」と呼んで、サービス メソッド内で例外をスローし、コントローラー内でキャッチする必要がありますか?

結局、技術的には大きな違いではありませんが、標準的な慣習に従って正しい方法で行いたいと思います。ご提案いただきありがとうございます。

編集: アプリによって生成された URL が有効で存在していると仮定します。ユーザーがクリックすると、特定の ID を持つユーザーが見つかるはずです。ユーザーがブラウザーのアドレスバーに URL を手動で入力して、間違った (存在しない) ユーザー ID で URL にアクセスしようとした場合の対処方法を知りたいです。

4

3 に答える 3

4

私が正しく理解している場合、ユーザー ID を含むリクエストはクライアントからのものです (あなたの制御外です)。引用した経験則を適用すると、無効なユーザー入力は完全に予想されるケースであり、例外は必要なく、適切なエラーメッセージをクライアントに返すことで null 値を適切に処理します。

(OTOH リクエストのユーザー ID が別のアプリによって自動的に生成された場合や、DB などから取得された場合、無効なユーザー ID は予想外であるため、例外が適切です。)

于 2011-01-23T13:31:03.550 に答える
0

私の個人的な提案は、エラーの詳細 (IP アドレス、無効なユーザー ID) をログに記録し、エラーが発生して管理者に通知されたことを示すエラー ページにユーザーをリダイレクトすることです。so-n-so リンクをクリックして、ホームページなどに戻ります。

ポイントは、例外をスローするかリターンをスローするかに関係なくnull、応答がユーザーに返される前に、最も外側のフィルターまたはハンドラーが詳細を「ログに記録」することを確認してください。

于 2011-01-23T13:20:28.560 に答える
0 
What should I do when someone passes invalid user id inside the request URL?

2 つの選択肢があります。言及した「デフォルト」ページを表示するか、「見つかりません」/404 を返します。

nullに関しては場合によります。参照に対してnullを受け入れられないと考える場合は、それに注釈を付けます@NotNull。注釈は、 null参照を取得したときに正しいことを処理します。つまり、(チェックされていない) 例外をスローします (もちろん、驚くべき @ で作業する必要があります)。これが機能するための NotNull 注釈)。

チェーンの上流で何をするかはあなた次第です。ユーザー ID を偽造しようとしている誰かに 404 を返すことは、最適に近いと思います。

于 2011-01-23T15:56:06.633 に答える