この場合、例外をスローするのは完全に妥当と聞こえます。この方法は、1つのことと1つのことを実行するだけで、単にデータベースからユーザーレコードを取得しようとしています。前提条件がうまくいかない場合は、諦めてください。データベースのエラーが発生した場合は、あきらめてください。ユーザーが見つからない場合は、放棄してください。呼び出しコードがその結果を処理するようにします。
例外は、メソッドに対して完全に許容される終了パスです。
前提条件の場合、それを修正するのは方法の責任ではありません。これは呼び出し側コードの責任です。だから、ArgumentExceptionを何らかの形で投げ、呼び出しコードがそれに対処するようにしてください。データベースエラーの場合は
、どちらかそれをキャッチし、それに応じて処理するアプリケーションのためのカスタム例外（InfrastructureFailed例外のようなものを）投げます。基本的に、アプリケーションには技術的な問題があることをユーザーに伝える必要があり、後でもう一度試してください。
ユーザーが見つからない場合は、ログインに失敗したように見えます。 SecurityExceptionの何らかのものを投げ、呼び出しが失敗したことをユーザーに通知して呼び出し元のアプリケーションに処理させます。 （具体的な例はありません。たとえば、ユーザー名は問題ないがパスワードは悪いとユーザーに伝えないでください。悪意のあるユーザーには、必要以上に多くの情報が与えられます。 more）
パスワードが短すぎる場合もあります。私は、それがこの時点までに検証されるべきものだと思います。この場合、メソッドの入力チェックの対象となります。したがって、前提条件は失敗し、メソッドはデータベースに到達しようとすることさえありません。しかし、 "パスワードが短すぎる"とは、ログインプロンプトでユーザーに知らせるのは良いエラーではないでしょう。むしろ、それは彼らがを作成しようとするときのためにパスワードを作成するためです。
あなたがしてはいけないことは、nullまたは空のユーザーオブジェクトまたはそのようなものです。これは、エラーがあるかどうかをチェックするために、呼び出しコードにonusを置きます。例外は、呼び出しコードにエラーを通知するための完全に有効な方法です。返される「マジックオブジェクト」は、コード内の他の「マジックストリング」とまったく同じですが、メソッドから漏れて他のコードに流入するため、悪化します。
これはもちろん、必ずしも完全なルールではありません。それはアプリケーションの構造に依存します。たとえば、これがWebサービスまたは他の種類の要求/応答システムである場合、障害を示す標準的な応答オブジェクトが必要な場合があります。それは、しかし、メソッドの周りにいくつかのアプリケーションのコンテキストを想定しています。その場合は、おそらくで、は複数の方法を扱っているはずです。内部のメソッド（ドメインロジックメソッド）は例外をスローし、外側のもの（アプリケーションのUX対応メソッド）は例外をキャッチし、UIに対して適切な非null応答を作成します。
どのようにを処理するかは、ですが、例外はアプリケーションの論理構造に依存します。しかし、を投げてとをキャッチすると、キャッチは例外です（「キャッチ」は意味的に「ハンドリング」と同じではありません）。
メソッドの契約に合致しないパラメータなど、例外的な（予期しない）何かが発生したときに例外（...ドラムロール...）をスローします。 –
DBから既存のユーザーを取得することは、契約で指定することはできません。この情報をメソッドの呼び出し側に返す必要がありますか？ – m3th0dman