1

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.

Maslow
  • 18,464
  • 20
  • 106
  • 193

4 Answers4

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.

  • 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 Feb 16 '10 at 19:58
  • 1
    Enterprise Library philosophy is that logging is an added-value service for applications, so any failure in the logging process must be handled gracefully without raising an exception to the main business process. The Logging block achieves this by sending all logging failures to a special category which is named Logging Errors & Warnings. By default, these error messages are written to Windows Event Log, though you can configure this category to write to other targets using different trace listeners if you wish. – Grigori Melnik Apr 11 '11 at 15:04
  • As to dependencies, the only DLLs LAB depends on are these: Microsoft.Practices.EnterpriseLibrary.Common.dll Microsoft.Practices.Unity.dll Microsoft.Practices.Unity.Interception.dll Microsoft.Practices.ServiceLocation.dll which are the core of the EntLib’s plumbing. – Grigori Melnik Apr 11 '11 at 15:05
  • @GrigoriMelnik: ELLAB has gotten better since I answered this question over a year ago. Hope they have also fixed the issues where it is nearly impossible to figure out why it doesn't work. And I'd still consider a logging library that has four external dependencies is still kinda heavy for its own worth. Fine if you're also using Unity and other parts of the El, but not so much for a plug and play logging library. –  Apr 11 '11 at 16:44
  • The on-failure behaviour of the Logging Block I described above has been present at least since v2.0 (January 2006). The only improvements you should see since a year ago are in perf and the config tool. Take a look at the video linked from http://bit.ly/hxDaHN starting minute 18:00. – Grigori Melnik Apr 12 '11 at 02:50
  • @GrigoriMelnik: Glad to hear it. I eventually dropped ELLAB when I couldn't figure out (after a few days of troubleshooting) why sql logging was failing. I wasn't able to get any errors whatsoever or figure out where I needed to plug in to get a notification of failure (this was before SO, of course). –  Apr 12 '11 at 12:56
3

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?

Grigori Melnik
  • 4,067
  • 2
  • 34
  • 40
2

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});
Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
derfy74
  • 21
  • 1
  • I cannot get reference to instrumentation, because logger.writer doesn't have method GetInstrumentationEventProvider. Is this enterprise library 5? – Jiří Herník Sep 04 '13 at 06:34
1

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
  • 1,853
  • 3
  • 14
  • 19
  • 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 Feb 16 '10 at 19:57