You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Simon Kitching <sk...@apache.org> on 2005/05/24 00:44:22 UTC

Re: [logging] throwing exceptions on log configuration [was a candidate explanation...]

On Mon, 2005-05-23 at 20:58 +0100, robert burrell donkin wrote:
> On Sun, 2005-05-22 at 15:59 -0700, Brian Stansberry wrote:
> > One unsatisfactory aspect is that instead of throwing
> > an exception with a nice message and stack trace,
> > logging would mysteriously be done using an unexpected
> > logging library.  But Simon's recent work on adding
> > diagnostics should help mitigate this drawback.
> 
> i think that this comes down to a question of philosophy. 
> 
> the consequences of throwing an exception are usually pretty fatal for
> an application. personally, i think that we'd be doing most users (who
> just want to run their application) a favour by ensuring that discovery
> throws as few exceptions as possible. i hope that diagnostics and a good
> troubleshooting document would prove a good enough substitute for those
> who want to choose a particular logging system.
> 
> then again, this opinion has traditionally been in the minority so i'd
> be happy to go with the consensus on this issue...

Given the availability of diagnostics, I would now be in favour of not
throwing exceptions, ie following log4j's "failsafe" approach as far as
possible. It's a difficult call, as different people will want different
things, but the logging output *will* go somewhere; on config error, it
just goes to a "higher level" logger than expected, eg the tomcat log
instead of the webapp log. That should be noticed fairly quickly if it
happens.

But I would like to see a separate patch for fallback-on-failure than
for the test-availability-by-instantiating-logger stuff.

Regards,

Simon



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org