By: Arjun Chakraborty

Let’s face it; try as we may, rarely does our code come out perfect, and then we need to debug it to death, until we cry ourselves to sleep for being inadequate programmers.  Fortunately, clever debugging practices can make the debugging process relatively painless.  Practices such as:

4) Using a Notes Column:

If you are using a workflow, timer service, event handler, or even a custom app which handles SPItems, then consider adding a temporary multi-line text column called, say, CustomNotesField.

There are two ways to use this field.  You can keep replacing this field’s value with a flag value (item[“CustomNotesField”] = “flag 1”;), and then you will know how far your code went before crashing.  Secondly, you can keep concatenating to a string log variable, and at the end of your try/catch/finally block, post the entire log file, and you have quite a verbose log of what occurred in your code.  Another advantage of this method is that while the workflow history list usually truncates stack traces, an entire stack trace (in fact, multiple stack traces) can be stored in the CustomNotesField field.

3) Using a Notes List:

If you cannot use a notes column or absolutely do not want to update the SPItem, then consider using a custom list called DebugNotes.  This is really useful with event receivers.  At appropriate points in the receiver code, have the receiver add an item to the DebugNotes list, and change that item’s title to some useful message.  This will help you see if the receiver did in fact kick off, or if it went through the correct logical paths.  This will also help you know when a receiver kicked off multiple times by accident.

You can also get creative and add columns such as flag count, and notes.  Adding a multi-line text column called notes will be able to hold stack traces, and adding a flag count will let you know how many iterations were taken in any loops, or where in the code the execution was in when the log was made.

2) Using DateTime.Now:

When using either of the earlier methods, remember to concatenate DateTime.Now to the end of your logs.  This will not only let you know if an event receiver or workflow is taking too long, or if a timer service executes at the wrong time, but it will also remind you of what tests you ran and when, in case you leave for a lunch break or home, etc.

1) Using Version Counts:

Lastly, consider logging a version number whenever you update CustomNotesField or add an Item to DebugNotes. Then, before you compile your code, increment your version by 1.  This will make sure that the code executing on SharePoint is the correct one.  This will also remind you if you had in fact compiled the code before taking a lunch break or talking to your boss.  Furthermore, I’ve had incidents when a workflow was copied to GAC, but some methods did not update.  If I had not kept versioning inside the method, I would never have realized what went wrong.

Okay, I hope that helps!  Honestly, these techniques are not only good for debugging, but they are also good for testing.  While looking at the results of your customizations can tell you if it ostensibly works, adding these elements will make sure the meat of your code, what’s working under the hood, is running correctly as well.  Happy bug smashing!

By: Arjun Chakraborty