> Raising an exception in a logging framework is a horrible idea. You don't
> want your logging framework to break your application in production because
> of a typo...
>You can also create a static class to better control your actual categories.
Thus wrote itinsley@gmail.com,
>> Raising an exception in a logging framework is a horrible idea. You
>> don't want your logging framework to break your application in
[quoted text clipped - 3 lines]
> your application you would rather have it raising an exception than
> "working" in a way that is not how it's supposed to work.
But then I wouldn't call it logging. Logging is a operational necessity that
must not break.
> If you make
> a typo in a connect string you want your app to raise an exception and
> you deal with it accordingly. I see this (for my context) as similiar
> - if my app's not working as intended i would prefer to know about it
> when i start it up and then fix it rather than be blissfully unaware
> it is not working as intended until i find out some other way.
The difference is that connecting to a DB usually is a necessary step to
fufill some business logic, whereas logging isn't. If you need a guaranteed
write to some resource, a logging framework is likely the wrong tool.
>> You can also create a static class to better control your actual
>> categories.
[quoted text clipped - 6 lines]
> if the Category is missing) but i can't find how to do this - could
> you give me more details?
Sure. Fire up EntLibConfig.exe, open your .config file and expand the "Logging
Application Block" subtree in the tree view. Under "Special Sources", add
a trace listener reference to "Unprocessed Categories".
Cheers,

Signature
Joerg Jooss
news-reply@joergjooss.de