NLog will introduce a change to logging exception handling and suppression. In NLog 1.0 all exceptions were disabled by default, but could be enabled by setting
<nlog throwExceptions=”true”> </nlog>
or in code:
LogManager.ThrowExceptions = true;
This flag applied to configuration errors as well as runtime errors, which was problematic, because a simple configuration file typo could cause entire logging to be disabled silently.
To address this, NLog 2.0 will treat configuration errors separately from runtime errors. There will be two kinds of exceptions:
- Configuration exceptions – raised during parsing of configuration file and wrapped in NLogConfigurationException. Such errors are fatal and will prevent your application from starting (this is the same as having malformed App.config or Web.config). The errors that cause this exception are:
- syntax errors in NLog.config
- invalid target names
- invalid property names
- invalid property values
- Runtime exceptions (such as permission issues, connection failures, etc.) – raised during logging and initialization and wrapped in NLogRuntimeException. They can be controlled by throwExceptions flag.
I would love to hear your comments.
I need to handle NLog exceptions (Configuratio and Runtime) outside of the normal flow of execution.
What do you think about providing two events to handle exceptions:
LogManager
{
…
public event EventHandler ExceptionEventArgs ConfigurationExceptionHandler;
public event EventHandler ExceptionEventArgs ExceptionHandler;
}
That’s actually a very good idea as handling exceptions in Silverlight is problematic since due to asynchronous nature of networking in Silverlight, certain exceptions can be raised on different threads where the callback occurs.