Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,026 | Comments: 44,842

filter by tags archive

How NOT to write a logger

time to read 1 min | 173 words

I am going over some library code at the moment, and I am following my usual routine of starting at the basic infrastructure to find the fault lines. Take a look at this:

public void Log(string pSource, string pMessage, EventLogEntryType pEntryType) {
    try {
        if (!EventLog.SourceExists(pSource)) {
            EventLog.CreateEventSource(pSource, "Application");

        EventLog.WriteEntry(pSource, pMessage, pEntryType);
    catch (Exception _ex) {
        Log("", _ex.ToString(), EventLogEntryType.Error);
This is… impressive.



awesome, I almost missed the recursion


That is impressive. I think that will lead to a StackOverflowException, right?

According to the MSDN docs, calling EventLog.CreateEventSource or EventLog.WriteEntry with the source parameter set to an empty string ("") will generate an ArgumentException.

Therefore, if during the first run through the function it throws an exception, the catch block will try and call into the Log function again (recursively) using a blank string, which will generate another exception, until a stack overflow occurs.

That's my guess. :)

addy santo

down that path insanity lies :)


And than they say programmers don't have humor ;-)


This might be the most brilliant try...catch block I have ever seen.

Chris Smith

Genius. Sheer genius.


I guess it is a joke right?


While leads me to a question: What is the best way to log that your logger failed?


Maybe works fine for EventLogEntryType.Error.

is a joke


Heh I have seen this many times before, but on something like an error page, it would inherit the base page class which in on load would fail to connect to the DB and redirect to error page.

Endless redirect to error error error error, all the while sending error emails. That day I got 200,000 error emails from the site, fun fun fun.


Reminds me of something similar that we have where I used to work:

void Save() {




void Recalculate() {

try {

    // some stuff

} catch {




It's still there. "The "some stuff" shouldn't fail so why fix that part"

Of course, every once in a while someone makes a change and "some stuff" does fail, resulting in nasty bugs.

Mr Berre

Ugh, reminds me of a bit of code I discovered recently in the web ui for a new project I was working on. All aspx pages inherit from a base class, which contains a check whether a user is allowed to even see anything in the UI. If a user wasn't allowed to, he was redirected to Error.aspx, which of course inherited from the base class and which of course triggered the check...

The UI code was based on another project's code (no need to re-invent the wheel) that has been in use for 6+ months. I'm still amazed that they've never had an issue with that, since usually the business people are very good at pointing people to apps they don't have access to.




If at first you don't succeed...




I have seen this many times before, but on something like an error page,

Comment preview

Comments have been closed on this topic.


No future posts left, oh my!


  1. Technical observations from my wife (3):
    13 Nov 2015 - Production issues
  2. Production postmortem (13):
    13 Nov 2015 - The case of the “it is slow on that machine (only)”
  3. Speaking (5):
    09 Nov 2015 - Community talk in Kiev, Ukraine–What does it take to be a good developer
  4. Find the bug (5):
    11 Sep 2015 - The concurrent memory buster
  5. Buffer allocation strategies (3):
    09 Sep 2015 - Bad usage patterns
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats