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

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.