6

どのような状況でjava.util.zip.ZipFile.close（）はIOExceptionをスローしますか？そのメソッドシグネチャは、スローできることを示していますが、ソースコードからは、ネイティブコードでない限り、これが発生する可能性のある場所はないようです。その例外がキャッチされた時点で、もしあれば、どのような是正措置を講じることができますか？

4

4 に答える 4

7

上のAPIドキュメントからZipFile.close()：

このZIPファイルを閉じると、getInputStreamメソッドの呼び出しによって以前に返されたすべての入力ストリームが閉じられます。

そして、をInputStream.close()スローするIOExceptionので、ZipFile.close()それもスローする必要があります。のAPIドキュメントにInputStream.close()よると、 IOException「I/Oエラーが発生した場合」をスローします。それはあまり説明的ではありませんが、それは広いネットをキャストしています。InputStreamsは、ファイルシステム、ネットワーク、メモリなどからのストリームを表すことができます。InputStreamsには、フラッシュする必要のあるバッファー、閉じる必要のあるソケット、解放する必要のあるリソース、解放する必要のあるロックなどが含まれます。IOExceptionsさまざまな理由で発生します。

于 2010-05-04T15:13:29.587 に答える
1

男からclose（2）：

close（）の戻り値をチェックしないことは一般的ですが、それでも深刻なプログラミングエラーです。前のwrite（2）操作のエラーが、最後のclose（）で最初に報告される可能性は十分にあります。ファイルを閉じるときに戻り値をチェックしないと、データがサイレントに失われる可能性があります。これは、NFSおよびディスククォータで特に観察できます。

于 2010-05-04T15:05:40.320 に答える
0

よくわかりませんが、次のいずれかのイベントが発生するとIOExceptionがスローされると思います。

  • zipファイルがアプリケーション外の誰かによって削除されました。
  • zipファイルを含むドライブがマウント解除/切断されたとき

もっとたくさんのイベントが理由かもしれませんが、私が今考えることができるのはそれらだけです。

于 2010-05-04T15:13:14.097 に答える
0

のドキュメントは次のようにZipFile.close()述べています。

このZIPファイルを閉じると、getInputStreamメソッドの呼び出しによって以前に返されたすべての入力ストリームが閉じられます。

おそらく、ネイティブcloseメソッドはInputStreamsのクローズを実行しています。

のcloseメソッドは、チェックされた例外としてInputStream持っています。IOException

最も可能性の高い原因は、ファイルシステムのスペース不足状態で、基になるファイルシステムでzipファイルが書き込まれているエラーです。原因を特定してその場で回避できない限り、ユーザーに状態を報告するだけです。

于 2010-05-04T15:17:21.703 に答える