0

私はこの答えによって促されたscala-armライブラリを見ています、そしてそれはほとんどの文脈でリソースを管理するのに素晴らしいように見えます。

ただし、一見したところ、処理されていないように見えるコンテキストが1つあります。それは、リソースを別のリソースに「渡す」というコンテキストです。これは、I/Oを操作するときに頻繁に発生します。

for (fin <- managed(new FileInputStream(file));
     // almost what we want, except see below
     gzip <- managed(new GZIPInputStream(fin));
     src <- managed(Source.fromInputStream(gzip))) {
  /* some fancy code */
}

ここで、問題は次のとおりです。gzipが正常に作成された場合、 finを閉じる必要があり、finを閉じないでください（更新：これは正しくありません-二重閉じるのは問題ありません。受け入れられた回答を参照してください）。ただし、代替案：

for (src <- managed(Source.fromInputStream(
              new GZIPInputStream(new FileInputStream(file))))) {
  /* some fancy code */
}

完全に正しくありません-GZIPInputStreamコンストラクターに（明らかにありそうもない）エラーがある場合、FileInputStreamは閉じられません。同上fromInputStream。

scala-arm（または他のパッケージ）は、私がまだ見つけていないこのクリーンアップを安全に処理するための機能を提供しますか？

4

2 に答える 2

3

さらに数分見てみたところ、それは本当に問題ではないことがわかりました。java.io.Closeableすでに閉じられているclose()リソースを使用することはできません。したがって、すべてを包んmanagedで二重に閉じるのは安全です。したがって、最初のコード例は正しいです。

于 2012-01-05T17:34:55.333 に答える
1

私にとって最善のアプローチは、機能の世界で資金を調達しているiteratee、enumerator、enumerateeの概念を使用することです。

あなたが興味を持っているかもしれないのは、非常に優れた実装を持つScalazライブラリです。

言い換えると、これらの概念は、ソース上のイテレータの両方が、消費者がいつ消費を終了したかを知るためだけでなく、その逆も行うために使用されます。ソースを知っている短所を持つことは何も提供することはありません。

編集

iterateeの目的に関する非常に明確な投稿があります。あなたの問題について話している動機付けパラメータを見てください...うまくいったかうまくいかなかったときはいつでも、しかし適切なタイミングでリソースを閉じます

于 2012-01-05T21:33:40.833 に答える