Question

I created a simple a jQuery function that is to be used for developer event and error logging… it calls a web service function that simply logs several passed parameters to a log table called EventLog.

One of the parameters (logEventStr) is just a string that qualifies the log event… like ‘debug’, ‘error’, ‘user’, ‘info’… et cetera. I have all of these event types in another table, call it EventTypes, indexed (i.e. 1=debug, 2=info, 3=user…), and linked via foreign key constraint to an eventId column the log table.

So, during a code review it was suggested/argued that some initial checking on this log event string should be used since “a developer could possibly mistype the event type in the logEventStr parameter”. I explained that I have code in the web service that checks for a valid event string and throws an exception that is handled in the failure event of the Ajax call… it even prints out the misspelled event name error to the console, so the developer would immediately know that he messed up and would correct it. Further ‘discussions’ stated that the indexes in EventTypes should be hard-coded (probably a JSON object) in the javascript and checked before making the web service call. This just seemed silly to me, as now the developers will have to keep up with changes in the EventTypes table and keep them manually synced with the hard-coded JSON object. I finally relented somewhat to populating the JSON object with yet another web service call that returns the contents of the EventTypes table and caches it so it would be a one-time call on first hit. I still think, however, that even this is unnecessary… the logging function is only to be used by the developer and the logEventStr will never be dictated by an end-user.

My question is… which technique is right? How much checking should be required for something as straight-forward and simple as a logging function, that is to be used exclusively by the developers?

I’ve mulled this about over the weekend and it still bothers me. Of course, maybe neither of these is the correct approach, so alternative ideas are welcome.

Answer 1

Why not create a wrapper function for every log event type?

If your original function is log, and is used like this:

log("user", "is a zombie");

this could be rewritten as:

logUser("is a zombie");

where logUser simply calls log with the parameter user.

Another route to go would be to make log an object with various functions, so you would use it like this:

log.user("is a zombie");

etc.

The developers using your logging mechanism shouldn’t be bothered with its internals, and since we’re dealing with a logging system here, there is a finite amount of logging types, so if you put upfront a well thought out list of logging types that exist in the database and won’t need to be modified, then there shouldn’t be worries of something breaking in the future.

Edit (based on comment):

From your question, I see there are two tables, EventLog and EventTypes. I presume EventLog has two columns:

• eventId
• event,

while EventTypes also has two columns:

• eventId
• eventDescription.

This bit of information puzzles me, and I quote:

now the developers will have to keep
up with changes in the EventLog table

From my understanding, the purpose of this table is to store information about various events and their types. This table will change in sense that rows will be added every time an event is logged. No structural changes here.

The EventTypes table is the one that could change, and also in a way that new event types are added. This also means a row may be added.

Both tables won’t be modified in a way that their columns will be added or removed.

EventTypes is more or less “fixed”, and every event type is associated to a number. This number should be an “agreement” between your database and your Javascript.

So, if you have three rows like this:

• 1 | debug
• 2 | info
• 3 | user

then you should also have three functions like this:

• log.debug
• log.info
• log.user

and each one should call your webservice with appropriate number. This is your agreement.

If a new event type is added, so now your table has a new row like this:

• 4 | error

then you should add a new function for your developers:

• log.error

This way, there are no “breaking changes”, since new functionality is added and nothing old is broken in the process. Assuming your numbering scheme doesn’t change.

You just tell your developers “you’ve got a new function from now on, everything else will work like it did before” and you go ahead with your business.