avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: [PATCH] IOUtil.java additions
Date Thu, 05 Jul 2001 11:29:56 GMT
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:jeff@socialchange.net.au]
> 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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Mime
View raw message