On Jan 14, 2008 6:22 AM, sebb <[EMAIL PROTECTED]> wrote: > On 14/01/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Selon Siegfried Goeschl <[EMAIL PROTECTED]>: > > > > > Hi Luc, > > > > > > look at > > > > > > +) > > > > > http://commons.apache.org/sandbox/exec/xref/org/apache/commons/exec/StreamPumper.html#77 > > > > Couldn't this class be replaced by java.io.PipedInputStream and > > java.io.PipedOutputStream ? > > > > > > > http://commons.apache.org/sandbox/exec/xref/org/apache/commons/exec/DefaultExecutor.html#255 > > > > > > There a lot of ugly code during closing of the various Input/OutputStreams > > > > Yes, it is not really clean. > > > > > +) it is difficult to write correct code when you get problems during > > > cleanup and/or error handling and it is basically untestable > > > > I agree. It often ends up forwarding an IOException to caller and the caller > > simply displaying it and ending the application. However, I think this is > > the > > right thing to do. > > Not sure I agree with throwing Exceptions for cleanup code, as usually > no corrective action can be taken, and the error will often have no > effect on the rest of the application. (e.g. close() errors) > > However it may still be useful to know that the error has occurred. > This is where logging or status variables may be required. > > I agree here, but also with Luc's point above about logging not being part of the API contract. So the problem is how do you support the use case above and one more: configurable debug/trace information. I don't want to hijack this thread, but these two use cases are what has led me to look at adding logging to [dbcp] and [pool] and I am currently stuck on how to do it.
Phil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
