伊谢尔伦2017-04-18 09:27:05
実際、この問題についてはあまり心配する必要はありません。 JDK1.7 の try-with-resources に依存する必要はありません。
まずリソースを閉じて、try ブロックに入れます。必ず問題が発生します。リソースが閉じられていない可能性があります。
したがって、リソースの終了は 最後に に配置される必要があります。これについては疑いの余地がありません。
finally ブロックの close リソースに関しては、追加の IOE
が導入されることになりますが、これは避けられません。
現在 (私が見た限り) ほとんどのコードでは、IOE
をキャプチャした後、最大 1 つのログが記録されますが、多くの場合は noop、つまり no です。操作は何もしません 。
クローズ中に IOE が発生する可能性は非常に低いため、これを無視するのが正しい選択です。リソースのクローズ エラーが原因でシステムの実行が停止することはありません。さらに、この IOE をキャプチャすることに固執する場合、何ができるでしょうか?
finally ブロックに try-catch を導入したくない場合は、guava のクローズ メソッドを参照してください。closeQuietly() というツール メソッドを記述します。騒がないでください。
大家讲道理2017-04-18 09:27:05
あなたが追加した質問も IDE の問題によるもので、1 階の回答に同意します。
さらに、AutoCloseable インターフェイスと Closeable インターフェイスを実装するリソースの場合は、try-with-resources 構造を使用するのが最善です。
コードを例として取り上げます。一部のコードは省略されています
リーリーreadline と close の両方で io 例外が発生すると仮定します。JDK1.7 より前の例外キャッチ構造を使用すると、close 例外のみがキャッチされ、readline 例外は抑制されます。 (最終的にコードを実行する必要があるため)
別の質問ですが、try-with-resources 内のリソースの AutoCloseable の close メソッドはいつ実行されますか?
try コード ブロックが実行された後に実行されます (実験的なコードはここには掲載されません)。そのため、try-with-resources 構造を使用すると、catch ブロックとfinally ブロックはリソースが閉じられるまで実行されません。 。