23

を使用しStringReaderて、文字列を SFTP サーバーにアップロードできるものに変換します (ストリームが必要です)。StringReader後でそれを閉じることに何か意味はありますか？ソースを見る限り、文字列をnull...に設定するだけです

私はそれを行うことができましたが、close メソッドがスローとしてマークされてIOExceptionいるため、それを try キャッチでラップする必要があり、コードはおそらく必要以上に恐ろしいものに見えてしまいます。

4

5 に答える 5

13

StringReader捨てることになるとわかっているのなら、それを閉じる理由はないと思います。null閉じた後にそれへの参照を保持する理由は想像できないので、ガベージコレクション用に設定されている文字列には実際の利点はありません。を受け取るメソッドを作成していた場合Reader、基になる型がわからないため、メソッドを閉じるのが理にかなっている場合があります。

于 2011-05-25T09:14:11.520 に答える
6

それ以上のことをします。JavaDoc を引用する場合:

/**
 * Closes the stream and releases any system resources associated with
 * it. Once the stream has been closed, further read(),
 * ready(), mark(), or reset() invocations will throw an IOException.
 * Closing a previously closed stream has no effect.
 */

はい、そのリーダーを閉じる必要があります。リソースのためではなく、良いスタイルとあなたに従うかもしれないプログラマーのためです. このインスタンスがどこに渡され、他の誰かがそれを使って何をしようとしているのかはわかりません。いつの日か、インターフェイスを変更し、任意の Reader 実装を受け入れることを選択するかもしれません。その場合、リソースを解放するために close() の呼び出しを必要とする Reader を処理する可能性があります。

そのため、使い終わったら、このインスタンスをさらに (おそらく間違って) 使用しないようにするのは良いスタイルです。害はないので、将来起こりうるエラーを防ぐだけです。

編集: あなたが言うように、あなたの close() メソッドは例外を宣言している可能性があるため、 StringReader.close() は例外をスローしないため、 close() を呼び出す必要があると言えます。ただし、 Reader.close() は行います。したがって、すでに Reader の他の実装を許可しているため、最終的に取得する Reader の実装がわからないため、それを閉じる必要があります。そのスコープを離れることのない 3 行のコードについて話している場合は、変数 StringReader を宣言し、とにかく close を呼び出します (その場合は例外処理なしで)。

于 2011-05-25T09:21:14.890 に答える
4

厳密には必要ありませんが、StringReader は String のみを保持するため、適切な形式の問題として、とにかくすべての Reader を閉じることを常にお勧めします。現在、コードは StringReader を使用している可能性がありますが、実際に閉じる必要がある別の Reader に変更した場合、クローズなしのコードは間違っていますが、クローズありは問題ありません。

于 2011-05-25T09:24:36.060 に答える
-1

ストリームを閉じて、それに関連付けられているシステム リソースを解放した場合。ストリームが閉じられると、さらに read()、ready()、mark()、または reset() を呼び出すと、IOException がスローされます。以前に閉じたストリームを閉じても効果はありません。定義: インタフェース Closeable 内の close 定義: クラス Reader 内の close

于 2011-05-25T09:13:41.147 に答える