問題タブ [autocloseable]

この質問は、finalize メソッドの例外および同様の質問の反対です。

AutoCloseable適切に閉じないと重大なリスクをもたらすクラスを作成しています。そのような場合に、ユーザーがうっかり忘れないように、フェイル ハードを探しています。

一般的なベスト プラクティスは、Closeables が正常に失敗し、発信者のエラーを軽減するために最善を尽くすことですが、この場合、発信者はこれを見逃すことはありません。概念的にこの考えに同意しない場合は、フィードバックをいただければ幸いです。ただし、その場合、質問は Java の内部に関する学術的な演習と考えてください。

私が想像しているのは、クラスのメソッドが呼び出され、インスタンスがまだクリーンアップされていないIllegalStateException場合に、ユーザーを発生させて中断することです。finalize()ただしfinalize()、キャッチされていない例外を明示的に飲み込むため、これはトリッキーになります。RuntimeExceptionメソッドからユーザーに表示されるようにする最善の方法は何finalize()ですか?

ここに私がこれまでに得たもののデモクラスがあります:

注: また、finalize()実行が保証されていないことも認識しているため、このメソッドの周りに実装することは絶対に行われるわけではありません。GCが機会を与えてくれるなら、私はまだそれが起こることを望んでいます.

tryAutoCloseable-with-resources は素晴らしいですが、複数のオブジェクトをラップするクラスを作成する場合、効果的なリソース管理にはまだ十分ではないように思えます。たとえば、

このラッパーには少なくとも 2 つの問題があります。

1. 「bad-path」が無効で割り当てがr2スローされる場合、r1は閉じられません。
2. ラッパーの構築が成功した後にr1.closeスローされた場合、r2は閉じられません。

これらの問題はすべて対処できますが、2 つのリソースのみをラップする場合でも、ラッパーの作成は非常に簡単ではなく、エラーが発生しやすくなります。

ラッパーの作成を容易にするヘルパー クラスまたはその他の方法はありますか?

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

それは印刷します：

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

質問

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

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

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

C# では、 のメソッドで例外をスローすることは悪い習慣と見なされています。DisposeIDisposable

対照的に、Java では、 のcloseメソッドはAutoCloseable、例外がスローされることを許可し、呼び出し元に何らかの方法でそれを処理するように強制します。しかし、これが発生した場合、発信者は何をすることが合理的に期待されるのでしょうか? これは、リソースを閉じようとして失敗したことを示しています。ユーザーは続行する前に、おそらくある種の指数バックオフを使用して、リソースを再度閉じる必要がありますか?

AutoCloseableはjdk1.7で導入され、Cloesableすでにjdk1.5に含まれています。

そしてhttps://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.htmlによると

try-with-resources ステートメントは、各リソースがステートメントの最後で確実に閉じられるようにします。java.io.Closeable を実装するすべてのオブジェクトを含む、java.lang.AutoCloseable を実装するすべてのオブジェクトをリソースとして使用できます。

したがって、インスタンスはすでにステートメントCloseableでリソースとして扱うことができます。から拡張されtry-with-resourcesているため、これは確かです。CloseableAutoCloseable

私の質問は、なぜ Java が を特別に導入AutoCloseableするのか、なぜ Closeable のみをサポートするようにしないtry-with-resourcesのか、AutoCloseable を 以外に使用する方法はありますtry-with-resourcesか?

概要

私はクローズ可能な型を持っています。CloseableClassこれは、コンストラクター、メソッド、さらには内部で IOError をスローできますclose。私は try-with-resources を使用し、構築中のエラーを使用中のエラーとは異なる方法で処理したいと考えています (使用にはクリーンアップが含まれます)。さらに良いことに、保守可能なコードを書きたいと思っています。

クローズ可能なクラス インスタンスを構築し、それを try-with-resources ステートメントで使用したいとします。IOExceptionコンストラクターと、try-with-resources の本体で使用されるメソッドの両方をスローできます。

コンストラクターと本体でスローされたエラーを別々に処理したいとします。それを行うためのサポートされている方法はありますか? Python では、次のようにします。

ただし、Java では、オブジェクトに 2 番目の名前を割り当てないとできません。

これは主に の使用による「保守不可能なコード」であると言われましたがcloseable_、私はそうは思いません。それをエミュレートするというさらに悪い問題があるため、try-finally の使用は避けたいと思います。

closeこれには、テストクラスが従わないノーオペレーションであるために2回目の呼び出しが必要であることに注意してください（AutoCloseableこれは必要ではありませんが、必要ですCloseable）。closeこれは、投げられない場合は少し良くなりますが、それほどではありません。

基本的に問題は、

• close投げることができます
• 二IOException重印刷を防ぐために対処する前に閉じる"Body error!"
• try-with-resources の複数の初期化子で機能させる方法は明らかではありません
• とにかくコードを複製することになります。

「保守不可能なコード」で生活することを余儀なくされていますか、それともこれに対処するための良い方法を見落としていますか?

ケース A:

ケース B:

A の場合con、自動的に閉じられますps。ケースBrsはどうですか？ケース Bでは、変数がケース A のように作成されません。 conps

私の質問:両方のケースは完全に同一ですか? ケース Bに問題はありますか?