2

I have an application that writes to its own Event Source. The Event Source itself is created upon install to prevent user vs admin access issues at runtime.

Should writing to our own Event Source fail, the event is instead written to the Application log (two events actually, on for the original event data, and another saying 'Could not write to own event log because...' or something similar).

We've recently discovered a problem that when the Application event log is full, the exception is unhandled. Now granted, I could just eat the exception (similar to what this answer says).

So what is the best behavior? The application is attempting to log the issue and attempting to log that there is a problem. Should I eat the exception, let the logging operation fail silently and continue execution? Or should I let the exception bubble up the call stack so that user/developers know of the issue?

What's the recommended approach under these conditions?

Improve this question
1
  • Add the cycle option to that event source. It's not checked by default. – Coder Dec 8 '11 at 22:28
1

Use log4net with EventLogAppender. It can degrade gracefully and write to its internal logger why it has failed. You can easily forget worrying about maintaining your code that write logs to EventLogger.

Improve this answer
1

From your description it sounds like you should try to set up your own event log to overwrite earlier entries. But I am unclear as to why you log the events in the first place.

Just eating the exception, to me, indicates that you don't really want the log in the first place; it's a little like good ole VB's "On Error Resume Next". So if you're willing to eat the exception, you might be willing to just flush the log. If you don't - and continously eat the exception, the eventlog will be flawed as it will seem like no events have occured since the date it ran full.

If the exceptions are actually important, you should let them bubble up the stack so that a user/administrator will be forced to take action.

EDIT: I think if you have a machine where the user/administrator allows both your log and the event log to run full, while not allowing overwrites; (s)he probably doesn't really care. I think I wouldn't throw an error and halt execution - but rather try to notify more discretely - ie. activating a label or updating the status text or similar depending on your UI.

Improve this answer
2
  • Just to give context: this is not an application running on my Dev machine but a product to be deployed on client workstations at another business. Setting up the Application event log to overwrite will solve the problem... but there's nothing saying I have control over the target machine to do that (over-write policy defined by the site's IT administration etc etc). In the same breath: flushing the log = flushing events from all other applications. Not a good idea as these would be another business' workstations. So my question isn't so much a technical one but a design-philosophical one. – MoSlo Dec 8 '11 at 7:45
  • I understand - and I can see that my answer is somewhat unclear with regards to that. I'll edit later - but would you be able to setup your own event source to overwrite? – Anders UP Dec 8 '11 at 10:14
0

Depending on your needs one option would be to utilize the Microsoft Enterprise Library Logging block. I have successfully used it to log to flatfiles as well as internal databases. You can set the size of the log files and the behavior when a given file reaches it's max size. It's a pretty flexible (open source) library at least worth a look.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.