問題タブ [try-with-resources]

次の 2 つのオプションに意味上の違いはありますか? 自動リソース管理に関して、それらのいずれかが他のものよりも安全ですか?

オプション1：

オプション 2:

catchSonarQube の最新バージョン (4.3.2) を使用すると、try-with-resources ブロックにより、ラインのブランチ カバレッジに誤検知が与えられます。例えば：

しかし、私の単体テストはすべてのポイントでスローされた例外をカバーし、他のすべての行は 100% のカバレッジを持っています。実際のカバレッジは 100% です。そして、「8」はどこから来たのですか？例外がスローされる可能性がある場所は 8 つではありません。

問題の行に追加// NOSONARしてみたり、すべての行に追加してみたりしましたが、レポートは同じです。

を使用した場合、他の種類の問題は無視された// NOSONARため、ソナーの構成の問題ではありません。

それは、ソナーが、try-with-resources ブロックが生成するバイトコード内の追加の try-catch ブロックを許可していないためだと思います。

ソナーがこの特定の誤検出を正常に無視するようにコードを装飾する方法はありますか?

たまたま気づいたのですが、これが事実です。以下の例を参照してください。

それは印刷します：

クローズしてみてください。 最後に
キャッチ

質問

try-with-resources は、null チェックを伴う煩雑な最終セクションを回避し、リソースのリークを回避するように設計されています。catch セクションの前にリソースが閉じられるのはなぜですか? その背後にある理由/アイデア/制限は何ですか?

FilterOutputStream.close()これは、いくつかの問題を引き起こしている Java 8のメソッドへの変更でした。( http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/759aa847dcafを参照)

以前のバージョンの Java では、次のコードは例外をスローせずに機能していました。ただし、Java 8 では、try-with-resources メカニズムがストリームを閉じると、常に例外が発生します。

try-with-resources メカニズムは、最初に を呼び出しclose()ますdeflaterStream。deflaterStreamラップbosするので、データベースへの基outStreamになるストリームを閉じますdeflaterStream.close()。bos.close()outStream.close()

try-with-resources メカニズムは次に を呼び出しclose()ますbos。bosextendsであるためFilterOutputStream、flush()最初に で呼び出されoutStreamます。ただし、outStreamすでに閉じているため、outStream.flush()例外がスローされます。java.sql.SQLException: Closed LOB

他の誰かがこの問題を経験しましたか? もしそうなら、どのようにそれを回避しましたか？try-with-resources の使用方法に何か問題がありますか?

Java 7 から、インターフェースを実装するすべてのクラスがステートメントで動作できるように、インターフェースCloseableを拡張するようにインターフェースが改良されました。これまで、Closeable インターフェイスは、InterrruptedException を含む例外を自由にスローできました。ただし、Java 7 では、ステートメントで使用される Closeable インターフェイスのインスタンスは、try ブロックを終了した後に close メソッドが自動的に呼び出されると、InterruptedException をスローする可能性があり、暗黙的な呼び出しによって抑制される可能性があります。AutoCloseableCloseabletry-with-resourcestry-with-resourcesInterruptedExceptionThrowable.addSuppressed(InterruptedException);

誰かが無意識のうちに例外を抑制し、プログラムが本来の動作をしていない可能性があることを考えると、これは Java の下位互換性ルールに違反しますか?

たとえば、リソースのインスタンスをさまざまなオブジェクトに渡す必要がある場合はどうすればよいでしょうか?

try-with-resource の設計は (当然のことながら) そのメンバーの範囲を制限するように構築されているため、その種の設計上の問題にどのように対処するのでしょうか?

まだ try-with-resources を使用して、インスタンスを常に渡していますか? 通常の try-catch-finally ブロックを使用して、メンバーをそのスコープ外に保持しますか?

学校のプロジェクト用に AudioManager クラスを書き直していますが、問題が発生しました。私の教授は、try/catch を使用する代わりに、Try-with-resources ブロックを使用してすべてのリソースをロードするように私に言いました (以下のコードを参照)。javax.sound.sampled.Clip の Clip クラスを使用しています。Clip を close() しなければ、try/catch/ を使用する PlaySound(String path) メソッドですべてが完全に機能します。クリップを close() すると、もう使用できないことはわかっています。Clip と Try-with-resources の Oracle Docs を読みましたが、解決策が見つかりませんでした。だから私が知りたいのは：

Try-with-resource ブロックを使用して、クリップを閉じる前にクリップのサウンドを再生/聞くことはできますか?

前もって感謝します！

Java 7の機能を学びましtry with resourcesた。

catch ブロックでは、try(通常どおり) および from からの例外を処理する必要があります。finally

catch の前に finally が呼び出されたということですか? キャッチで Closeable リソースを処理したい場合はどうすればよいですか?

私の仮定を確認する観察結果が 1 つあります。

try ブロックが例外 1 をスローし、リソースのクローズ メソッドが例外 2 をスローすると、例外 1 がキャッチされ、例外 2 が抑制されます。