Suggestion:
IOUtil.copy (InputStream input, OutputStream output, boolean shutdown)
input - The input source.
output - The output source.
shutdown - Boolean flag indicating whether the streams should be closed.
The method is guaranteed to attempt to close both streams if the flag is
set.
Throws IOException - if the copying fails or if the streams could not be
closed. The method is guaranteed to attempt to close both streams if an
exception occurs in the copying and the shutdown flag is set.
Code is something like this:
void copy (InputStream in, OutputStream out) throws IOException {
copy (input, output, false);
}
void copy (InputStream in, OutputStream out, boolean shutdown) throws
IOException {
try {
// Copy
} finally {
if (shutdown) {
Throwable throwable = null;
try {
in.close ();
} catch (IOException ioe) {
throwable = ioe;
}
try {
out.close ();
} catch (IOException ioe) {
throwable = ioe;
}
if (throwable != null) {
throw throwable;
}
}
}
}
> -----Original Message-----
> From: Jeff Turner [mailto:[EMAIL PROTECTED]]
> Sent: den 6 juli 2001 02:44
> To: Avalon Development
> Subject: Re: [PATCH] IOUtil.java additions
>
> That approach works perfectly well whether or not the copy() method
> returns it's second arg. Likewise, if the copy() methods didn't return
> anything, it would be just as easy to write "bad" code. Returning the
> second arg simply gives users the option.
True, but then you only get to close one of the streams.
> Why was your app throwing 256+ IOExceptions during normal operation
> anyway? ;) Looking at FileOutputStream.finalize(), it does close() the
> stream, so all you needed to do was gc() occasionally.
Yes, but there is no guarantee that the 256 limit won't be used up by the
time the GC finally gets around to finalize the output stream. With a 1+ GB
heap, that might take a while...
> So to summarise, first I don't see how limiting the user's choice
> encourages "better" use.
With every API comes a different set of idioms regarding "how things are
done". For example, the way to download pages as you described will probably
make its way into documentation and become the way a new user of IOUtils
will use it. Pretty soon, that statement is all over Avalon/Phoenix/???
code.
If we make one "dangerous" way of using a class impossible, then the
programmer using the class will have one less thing to worry about.
That's why Java has checked exceptions - the method of having a return value
(as common in C programming) just made programmers ignore it. With Java,
exceptions are checked by the compiler, and thus you catch "dangerous" parts
at compile-time.
> and second I don't see why it is desirable to
> close() all streams manually in exceptional circumstances, when the gc
> could do it.
See above.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
