Details
Description
I understand that you do not want to throw exceptions
from within the logging methods, as a failure in log4net
would make the hosting app fail.
However, I think it is necessary that DOMConfigurator
throws exceptions. If a failure occurs at that point, for
example due to a malformed configuration file, I believe
the hosting app would in most cases like to know. Even
if it doesn't, it could easily just swallow any exceptions.
In my case, I have a Windows Service app that will just
quit logging if there is an error in the configuration file.
That makes the logging mechanism rather more fragile
than I would like.
Tor Hovland - torhovl
—
I completely agree. I suggest that you take an additional
step and provide an additional mechanism, perhaps a
ValidateLoggers() method which operates like a standard
logging call, but is capable of throwing exceptions or
providing another form of feedback which would allow the
caller to diagnose bad configurations. The configuration
file can be well-formed, but logging can still fail for any
number of reasons.
Most applications that provide a logging mechanism employ a
'start-up banner' log entry at an INFO level. This would be
a great time to detect any problems with the logging system
itself. I currently have a project deployed at a customer
site and despite a well formed config file... no logging is
taking place. I don't know why, and there does not seem to
be a simple way to diagnose the problem.
Ben Newman - benjamin91
Attachments
Issue Links
- is broken by
-
LOG4NET-377 XmlConfigurator.ConfigureAndWatch is not backwards compatible to 1.2.10
-
- Closed
-
- is related to
-
LOG4NET-7 Detecting NoAppenderWarning
-
- Open
-