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. > > +) having said that the caller currently has no indication that > > something is broken therefore logging would be a real improvement > > I don't agree. The caller cannot use logging to get indication. Logging is for > runtime monitoring (think some console window) or batch analysis. Logging is > not > a communication service between caller/callee (but I think I misunderstood > your > statement here). > > > +) adding a multitude of status flags (as proposed in the code) is > > obfuscation > > Yes. Status flags may be useful to forward errors from one thread to another > one > though. I encountered this in another exec-type library. The > input/output/error > streams were monitored by dedicated threads, while still another thread > monitored process execution. When all threads were finished (either nominally > or > by external interruption), then the possible error flags were collected and if > needed an exception was thrown in the launcher thread context that was waiting > for completion of the process. To summarize, flags were used but only for > internal purposes. From the launcher point of view, there was a simple > "launchProcess" method that may either return normally or due to an exception > if > some error case was encountered. This was very simple to handle. > > Luc > > > > > Cheers, > > > > Siegfried Goeschl > > > > [EMAIL PROTECTED] wrote: > > > Siegfried Goeschl <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > >> On the downside the current implementation silently drops so many > > >> exceptions that I feel a bit uncomfortable about it (or to state it more > > >> clearly I would reject such a code during code review) - so I have no > > >> final conclusion what to do > > >> > > > > > > I'm a little confused here. Logging is for me a way to trace what is going > > on, > > > including errors, but it is not by itself an error handling system. When I > > wrote > > > that low level components like [exec] must be robust and can avoid > > > logging, > > I > > > did not mean exceptions should be dropped. > > > > > > If exceptions are currently dropped, then this is a very bad thing and it > > must > > > be fixed before graduating from sandbox. Error modes for any component, > > either > > > low level or high level, belong to the public API. When an irrecoverable > > error > > > occurs, it must be forwarded up and explained in the javadoc. It must also > > > provide a meaningful (low level) error message with as much information as > > > possible in case the caller is not able to provide a better medium level > > error > > > message. Preserving or changing the exception type or the message is up to > > the > > > caller. I also think that since the caller may decide to display the error > > > message for end user, it should be localized. However, I remember some > > people > > > here do not share this point of view (see thread > > > http://markmail.org/message/msgyq6gpvhwqvzaa). > > > > > > Luc > > > > > > > > >> +) doing nothing is simple and straight forward > > >> +) passing a simple logger facade is a way to go but not terribly > > >> elegant (we call it "edelhack" in German) > > >> +) I'm not repeating all the other arguments here regarding logging > > >> frameworks but state that I have no favorite > > >> > > >> Cheers, > > >> > > >> Siegfried Goeschl > > >> > > >> Luc Maisonobe wrote: > > >> > > >>> Siegfried Goeschl wrote: > > >>> > > >>> > > >>>> Because using commons-logging is not undisputed and log4j/jdk logging > > >>>> would reduce the number of dependencies for a user > > >>>> > > >>> I agree. Lots of debate have already occured on this subject, and no > > >>> consensus reached. This simply shows this is a matter of taste, and > > >>> probably even passion. So there is no point in pushing one choice > > >>> among the users. I do have a favorite library too, but will neither > > >>> say what it is nor try to provide any argument for it. > > >>> > > >>> Removing a dependency is always a good thing for a library that is > > >>> intended to be a building bloc for some higher level application. > > >>> > > >>> Torsten Curd wrote: > > >>> > > >>> > > >>>> And I would argue that a library should be so robust that (at > > >>>> least preferably) it does not need any logging at all ...or if there > > >>>> is a problem you just debug it. > > >>>> > > >>> I also agree. Commons are quite low level components, they should be > > >>> as lighweight as possible. They should neither impose some framework > > >>> to work nor make any assumption on how they will be used. They should > > >>> be robust and simple enough to not need logging *inside* themselves. > > >>> > > >>> Luc > > >>> > > >>> > > >>> --------------------------------------------------------------------- > > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >>> For additional commands, e-mail: [EMAIL PROTECTED] > > >>> > > >>> > > >>> > > >>> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > >> > > >> > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
