Hi Luc,
look at
+)
http://commons.apache.org/sandbox/exec/xref/org/apache/commons/exec/StreamPumper.html#77
+)
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
+) it is difficult to write correct code when you get problems during
cleanup and/or error handling and it is basically untestable
+) having said that the caller currently has no indication that
something is broken therefore logging would be a real improvement
+) adding a multitude of status flags (as proposed in the code) is
obfuscation
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]
