Since I started with functional languages and programmed in Pascal and C in my first couple of years of experience, I didn't get too carried away with OOP ... for extended periods. The obsession usually lasted for a month or so before I got practical.
The other day, I interviewed a guy who has been a business analyst. He had all the technical jargons of the past 10 years in his resume. If he could show some UML, I would have considered him for an analyst role. If he could write code, I would have considered him for a tech lead role. If he could do both, I would have him take my job. The person threw bull and jargons at me at an alarming frequency. Every sentence had stake holders or components or some such shit that are candidates for stop words in a management meeting.
Since he started talking about a requirement for logging, I asked him to design a logging system. If he could just copy Log4J, I would have been happy. If he could write a simple function declaration, that takes a bunch of relevant parameters, I would have been happier. He kept talking about it for full 45 minutes with out writing anything.
I thought he could be a Manager in some ISO/CMM type company and wished him good luck.
Let me try writing a declaration for logging.
void LogIt(int level, string systemName, string errorMessageFormatString, Object[] params);
- The first parameter could be cleaned up by using an enum with values from {Critical, Error, Warning, Info}.
- The second parameter can be used for source file name, or a combination of both.
- The third and fourth parameters work together like the String.Format function.
- The function is not supposed to return anything or throw exceptions. I recently came across a java application that couldn't report the actual exception as it threw one more exception in logging the error.
- If you want to OOP it, encapsulate it in an interface with more complex logging function. There could be multiple implementations of this depending upon the mode of logging - display, file, event log, email alert and what not! And it is no more simple.
- With C/C++ macros, this could be even simplified... with some dirty macros.
2 comments:
That was a simple logging mechanism I don't think it can get simpler.
On your point that the logging funtion should not throw any exception, if the logging is happening to a file/table, then exceptions (like FileNotFound, db-related Exceptions) do come into the picture, right ?
Logging should be as least intrusive as possible. You would have probably fixed some the exceptional cases of logging (like path not found) in your testing or when you smoke tested the app on production. Exceptions like disk full caused by logging alone is bad, often implies that logs are not cleared and/or unwanted stuff gets logged.
Well, the idea is logging should not affect the normal functioning of the application.
Post a Comment