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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
