0

こんにちは。Javaでダミーのライブラリ管理プロジェクトを作成して、OOPを学習しています。

serachBook（）では、bookがArrayListで見つかった場合はbookオブジェクトを返し、見つからなかった場合はカスタム例外BookNotFoundをスローします。

質問1：nullを返し、呼び出しコードでnullの戻り値を確認するか、カスタム例外BookNotFoundをスローする必要があります。

現在、BookNotFoundが適切であると信じており、現在それを行っています。ただし、もう1つ問題があります。addbook（）では、最初にsearchBook（）を呼び出して、本がすでに存在するかどうかを確認します。存在しない場合は、本を追加します。ただし、本が存在しない場合、searchBook（）はBookNotFoundをスローします。

Qestion 2：addBook（）がリストに本を挿入するには、BookNotFound例外が発生する必要があるため、addBook（）でsearchBook（）によってスローされたこの例外をどのように処理する必要がありますか。だから私は空のCatch（BookNotFound e）{}を書くべきですか？

より良いOOの実践は何でしょうか？

4

5 に答える 5

3

null本が見つからない場合は戻って、メソッドドキュメントに記載する必要があります。

Exceptionスローはコストのかかる操作であり、例外的な場合にも適しています（searchBook()メソッドでnullを渡した本の名前など）

于 2013-01-01T06:45:19.817 に答える
2

戻りnullます。

プログラムフローを制御するために例外を使用することは非常に悪い考えです。例外は例外のためのものであり、見つからない本は例外的なケースではありません。

例外のスローは、メソッドが状況を処理できず、呼び出し元にそのことを通知したい場合に実行されます。を返すことで処理できますnull。

null同様の状況で返されるJDKクラスの例はたくさんあります。たとえば、キーがマップに見つからない場合にMap.get(key)返されます。null

于 2013-01-01T06:56:50.233 に答える
0

私の提案は、本が見つからない場合に「null」を返すオプションをはるかに超えることです。例外は「それほど日常的ではない」シナリオを処理するためにのみ使用し、説明から「本を検索」と「本を追加」はかなり一般的なシナリオのように見えます。

例外の使用にはオーバーヘッドが伴います
。Java例外はどのくらい遅いですか？
http://apmblog.compuware.com/2011/04/12/the-cost-of-an-exception/

于 2013-01-01T06:48:11.950 に答える
0

質問1：
例外は例外的な条件のためのものでなければなりません。
存在しない本は例外的な状態のようですので、null代わりにのような特別な値を返す方が適しています。
http://codeutopia.net/blog/2010/03/11/should-a-failed-function-return-a-value-or-throw-an-exception/

質問2：
また、例外を決して食べないでください。
代わりに、catchブロックに本を追加するコードを記述して、ロギングなどの便利な処理を実行できます。

于 2013-01-01T06:48:48.383 に答える
0

代わりに、nullifBookが見つからない場合は返し、それに応じて処理する必要があります。

例外のスローはコストのかかる操作であり、その名前が示すように、これらは例外的な条件です。したがって、アプリケーションのフローを制御するコンテキストでそれらを使用することは、実際には悪い習慣と見なされます。

さらに、フロー制御に例外を使用すると、驚き最小の原則に違反し、プログラムを読みにくく、理解しにくくします。

また、コンパイラベンダーはこれを期待していません。彼らは例外がめったにスローされないことを期待しており、通常、スローコードを非常に非効率的にします。

于 2013-01-01T06:54:32.133 に答える