On 2011-08-17, Honton, Charles wrote:
> Why guard against closing System.in? If the client application needs that
> sort of functionality, it should wrap the incoming stream in a proxy that
> doesn't delegate the close method to the underlying stream.
You and I agree here - there even has been a
Why guard against closing System.in? If the client application needs that
sort of functionality, it should wrap the incoming stream in a proxy that
doesn't delegate the close method to the underlying stream. (A new class
for commons-io?)
Chas Honton
On 8/16/11 11:16 PM, "sebb" wrote:
>On 17
On 17 August 2011 06:18, Stefan Bodewig wrote:
> On 2011-08-17, sebb wrote:
>
>> On 17 August 2011 03:42, Stefan Bodewig wrote:
>>> On 2011-08-15, sebb wrote:
>
For input, there might be a use case for leaving the stream open, in
case some kind of recovery is possible.
>
It would b
On 2011-08-17, sebb wrote:
> On 17 August 2011 03:42, Stefan Bodewig wrote:
>> On 2011-08-15, sebb wrote:
>>> For input, there might be a use case for leaving the stream open, in
>>> case some kind of recovery is possible.
>>> It would be useful to have a way of determining the input file point
On 17 August 2011 03:42, Stefan Bodewig wrote:
> On 2011-08-15, sebb wrote:
>
>> On 15 August 2011 09:56, Stefan Bodewig wrote:
>>> Hi,
>
>>> while working on the Zip64 stuff I deliberately created some invalid
>>> archives to test I get the expected exceptions. While doing so I
>>> realized I c
On 2011-08-15, sebb wrote:
> On 15 August 2011 09:56, Stefan Bodewig wrote:
>> Hi,
>> while working on the Zip64 stuff I deliberately created some invalid
>> archives to test I get the expected exceptions. While doing so I
>> realized I couldn't close the underlying stream because
>> ZipArchive
On 15 August 2011 09:56, Stefan Bodewig wrote:
> Hi,
>
> while working on the Zip64 stuff I deliberately created some invalid
> archives to test I get the expected exceptions. While doing so I
> realized I couldn't close the underlying stream because
> ZipArchiveOutputStream's close would throw a
Hi,
while working on the Zip64 stuff I deliberately created some invalid
archives to test I get the expected exceptions. While doing so I
realized I couldn't close the underlying stream because
ZipArchiveOutputStream's close would throw an exception as finish()
failed before ever closing the wrap
