views:

193

answers:

2

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.

+1  A: 

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.

Will
I've not done anything in the Enterprise library yet, everytime I see something I want to try I jump on the EL is hard bandwagon, research reviews and comparisons, and see that the reviewers think another framework is more robust and easier for a particular block
Maslow
A: 

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.

decompiled
how would that work in the scenario where I want fallbacks to other systems, can you have multiple EL logging blocks in the same app? or is it going to cause major .config file spaghetti?
Maslow