+972 52-548-6969
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.
Comments
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. :)
Ka-Booom!
down that path insanity lies :)
And than they say programmers don't have humor ;-)
Nice one.
This might be the most brilliant try...catch block I have ever seen.
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() {
}
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.
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.
This is what they call "dog fooding" :)
sfa
If at first you don't succeed...
Brillant!
I have seen this many times before, but on something like an error page,
Comment preview