commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [exec] How to support the various Logging APIs?!
Date Mon, 14 Jan 2008 11:58:40 GMT
Siegfried Goeschl <> 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


> +) 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:
> > For additional commands, e-mail:
> >
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message