1

キュー インターフェイスを実装するカスタム キューを作成しています。この実装はスレッド セーフであり、場合によってはブロックされます。

InterruptedException通常の Queue インターフェースは例外について言及していないため、実装で例外をスローすることはできません。

この問題には 2 つの解決策がありますが、どちらも満足できるものではありません。

  1. Queue インターフェイスを削除し、例外をスローします。これにより、Queue を必要とする外部ソフトウェアでコードを使用できなくなります。

  2. スローRuntimeException、これにより、非常に驚​​くべきソフトウェアアクティビティが大量に発生しますが、リスクを冒したくありません。

どういうわけか、実装のようなArrayBlockingQueue実装QueueとBlockingQueue. それは行くべき道ですか、それともここでのトリックは何ですか?

4

2 に答える 2

2

Queueをスローする必要がある可能性のある を実装している場合、本当にBlockingQueueInterruptedExceptionを実装する必要があると思います。このインターフェースの javadoc を読むと、Java 言語の設計者が基本的に、通常の操作のコンテキストでは成功するかすぐに失敗するかのいずれかであると述べていることに気付くでしょう。このインターフェースは、メソッドが成功しない場合は をスローし、メソッドが失敗した場合は戻ります。新しいメソッドおよび とのオーバーロードされたバリアントは、ブロックする可能性があり、したがって.BlockingQueueQueueQueueIllegalStateExceptionaddfalseofferputtakeofferpollBlockingQueueInterruptedException

于 2011-10-29T03:53:25.277 に答える
1

オプション1を選択する必要があります。

キュー（インターフェイス）を手元に置きたい場合、キューが特定の方法で機能することを期待します。動作はインターフェイスで指定され、クライアントは実装について心配したり、切り替え時に変更を加えたりする必要はありません。

これはキューには当てはまりません。このインターフェイスを実装しても実行時例外をスローすると、予期しない方法でクライアントの期待を破ることになります。外国のソフトウェアは、互換性のないものを取得するために「だまされ」たくないという理由だけで、キューを要求します。

オブジェクト内で割り込み例外を透過的に処理できない限り、キューを実装しないことでこれを明示的にすることをお勧めします。

于 2011-10-29T03:31:14.433 に答える