Let's see what are the SharePoint 2010 Client Object Model internal characteristics. We have already seen the introduction article and an overview of CRUD operations on items and lists, today we are going to see which are the techniques to manage the client-side exceptions in one of the operations we have seen so far in the content in our SharePoint sites.

Frequently, when the operations are executed client side, we need to make a choice and execute some operations that depend on the presence of an exception or not.

So far, we have used try and catch block types to give the application some functionalities. For example, if you want to access a specific list in the SharePoint 2010 site in order to modify a property (in the example below you'll find the "OnQuickLaunch" property), from an application being executed out of the SharePoint context, you can write a code fragment like this to be sure that you modify the correct list and see this modified list in the site:

ClientContext context = new ClientContext("http://sharepoint2010");
using (context)
{
    try
    {
        List l = context.Web.Lists.GetByTitle(listName);
        l.OnQuickLaunch = false;
        l.Update();
 
        context.ExecuteQuery();
    }
 
    catch
    {
        ListCreationInformation info = new ListCreationInformation();
        info.Title = listName;
        info.QuickLaunchOption = QuickLaunchOptions.Off;
        info.TemplateType = (int)ListTemplateType.GenericList;
        context.Web.Lists.Add(info);
 
        context.ExecuteQuery();
    }
}

If the list is present in the SharePoint site, I modify the property and update, otherwise I create again the list from scratch applying immediately the modification.

Note: using the try and catch block to control if a list is present in a SharePoint site is just one example. There are many other methods, more or less performing, to control if a list in present in a SharePoint site.

If you use SharePoint 2010 Client Object Model, it is not convenient to use the try and catch blocks in the operations. The reason why is very easy to understand: we are in a client-side context and we have to pay attention to the number of queries to the server in order to execute our operations, in this way we have already made two queries.

In fact, the ExecuteQuery of the ClientContext class is called, for the first time, after the first update and the second time after the creation of list, if the previous action fails.

This is not an application type problem, but only a matter of performance.

Now we should know that the SharePoint 2010 Client Object Model makes available a particular class that allows a different kind of exception management. This is the ExceptionHandlingScope class, with its StartScope, StartTry, StartCatch and StartFinally methods, it allows to execute, in the same way, operations that depend on possible exceptions.

Let's see then how the first example is changed using such class:

ClientContext context = new ClientContext("http://sharepoint2010");
using (context)
{
    ExceptionHandlingScope scope = new ExceptionHandlingScope(context);
    using (scope.StartScope())
    {
        using (scope.StartTry())
        {
            List l = context.Web.Lists.GetByTitle(listName);
            l.OnQuickLaunch = true;
            l.Update();
        }
        using (scope.StartCatch())
        {
            ListCreationInformation info = new ListCreationInformation();
            info.Title = listName;
            info.QuickLaunchOption = QuickLaunchOptions.Off;
            info.TemplateType = (int)ListTemplateType.GenericList;
            context.Web.Lists.Add(info);
        }
    }
 
    context.ExecuteQuery();
}

As I told you before, the ExceptionHandlingScope allows the same operation, but with, at least, one less call to the SharePoint server. Therefore, it being understood that it is a technique that allows to improve the client-side applications, here you have all the advantages and disadvantages using this technique or maintaining the use of the try and catch block:

Use of the "Try and catch" block:

• There are at least two calls to the server
  
  
• Having multiple calls to the serve, the debug operations are more complicated.
  
  
• The code is more clear, more connected to the programming we have done so far.

Use of the "ExceptionHandlingScope" class:

• Calls to the server can be reduced.
  
  
• Reducing the calls to the server, the debug operations are much easier.
  
  
• At first sight, the code may not look that clear.