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]
