G�ran, Programmatically detecting configuration errors is an area which needs to be improved. There is currently no specific mechanism for doing this.
Apart from testing the LogManager.GetRepository().Configured property which indicates if the repository has ever been successfully configured the only other thing to do is to get the list of appenders defined using log4net.LogManager.GetRepository().GetAppenders(). This will allow you to test if the expected number and types of appender have been read from the config file. This does not indicate if the appender will actually work correctly when logging events are appended. To detect runtime errors each appender has an ErrorHandler property (from the AppenderSkeleton base class). The ErrorHandler is used to report a runtime error in an appender. It is possible to configure the ErrorHandler for each appender via the config file. A custom error handler implementation could raise an event in your application notifying of an issue with the logging appenders. Cheers, Nicko > -----Original Message----- > From: G�ran Roseen [mailto:[EMAIL PROTECTED] > Sent: 03 May 2005 13:35 > To: 'Log4NET User' > Subject: Detecting Internal Errors > > > Hi guys, > > I feel a little stupid here, but no matter how much I browse > through the SDK, I come up with zilch... > > How should my application detect that an internal error has > occurred in log4net? > I see that the case with a bad configuration file can be > detected by testing LogManager.GetRepository().Configured, > but how do I detect other errors? If say, a FileAppender for > some reason is unable to open the file. > > I also have some vague memory of seeing a > NoAppendersConfiguredError, but I can't find it now. > > Let's turn this question into something more general; What > would you think are examples of good practises on how to > implement log4net robustly in a production environment? > Personally, I would like to do a series of tests in the > startup of my app, just to make sure that the people that are > running the applications (skilled, but not necessarily > developers) get decent information when something happens... > > /G�ran > >
