Enterprise Library Logging Application Block optio

Question

Is the logging application block able to handle these situtations or combinations of them?

• If logging fails, do not throw an exception
  • for specific exceptions/exception types only
• If logging fails, fallback to another type(ie database logging fails, fall back to emailing or net send)

Example of my actual usage case:

I am writing a ticketing system for our team. If emailing the team on a new ticket creation fails, I want it to report that to the exception/error log, but not bubble that up to the user, regardless of how deep in the fallback stack the logging fails, the user doesn't need an error message, the ticket saved. some error locations/exceptions I would want bubbled up, but most of the ones I'm dealing with right now I do not.

Answer 1

if logging doesn't throw you can use the failureLoggingError event of the class LoggingInstrumentationProvider in this way:

LoggingInstrumentationProvider instrumentation = Logger.Writer.GetInstrumentationEventProvider() as LoggingInstrumentationProvider;

instrumentation.failureLoggingError += (s, z) => { throw z.Exception; };

....

....

//Logging code

 Logger.Write(new LogEntry() { Message = "bla bla", Severity = TraceEventType.Critical});

Answer 2

Maslow, please read my comments to other responses. In addition, I highly recommend you read this chapter of the Developer's Guide - As Easy As Falling Off a Log.

I would not advise to roll out your own logging infrastucture. Why not to use something mature that you don't have to maintain and instead focus on the business logic of your app?

Answer 3

My experience with the ELLAB was that when it doesn't work its nearly impossible to figure out why. Logging is such a (normally) trivial-to-implement part of a system relying on such a heavyweight component such as the ELLAB which can be an utter pain to work with sometimes is pointless.

I've used three logging platforms--Log4Net, ELMAH and the ELLAB--and have rolled my own. ELLAB comes with dependencies on the other parts of the EL and requries heavy lifting to get up and running. L4D L4N is a slimmer version of ELLAB which is easier to get going and offers equivalent functionality. ELMAH is a great library for logging errors in websites.

I'd suggest using L4N before ELLAB, especially if you aren't using any other EL blocks. If you're relying heavily on the Enterprise Library, ELLAB may be your best bet; good luck if nothing happens, however. Websites should definitely use ELMAH. And if you're writing a smaller app think about rolling your own log code.

Answer 4

I use ELMAH for web logging and the EL Logging Block for everything else. I have found that the EL Logging Block is flexible enough to do what you have asked.

I would wrap the logging logic into some logging class and handle the exceptions how you see fit.