Microsoft SharePoint is a great development platform but it have some major areas where it could be improved. As of today you can create mediocre applications using the current SDK (which is not so well documented), but to create great applications you really need to understand how the internals of Windows SharePoint Services really works!
I would like to show you an example of how bad the documentation and implementation is with a pretty common scenario.
The problem
Assume that you need to get your hands on an SPList object using the name of the list. MSDN contains an article called Development Tools and Techniques for Working with Code in Windows SharePoint Services 3.0 which has an example which goes like this:
try
{
// -- Check if list exists.
SPList list = web.Lists["MSDN Tasks"];
}
catch
{
...
}
This is the way to do it, except that you should use some nicer exception handling and not catch a generic exception. So take a look at the MSDN documentation for this one, there is no work about the exception or anything, not even that it fires an exception when not found. Most examples I see catches the base Exception class to be safe (and most often around larger code blocks than this!):
try
{
// -- Check if list exists.
SPList list = web.Lists["MSDN Tasks"];
}
catch (Exception ex)
{
...
}
Any list or collection should throw an ArgumentOutOfrangeException or at least ArgumentException in these cases, nothing about that on MSDN. As I really like to have things in order, a quick check using Reflector on the methods shows that an ArgumentException is really thrown under these circumstances. So the correct way is to write:
try
{
// -- Check if list exists.
SPList list = web.Lists["MSDN Tasks"];
}
catch (ArgumentException ex)
{
...
}
This is not only the correct way (with or without documentation), it’s the only. Imagine that you have this piece of code in your application and you frequently makes this check – how about performance. We all know that exception handling is process-cycle consuming, so this can be a real performance bottle neck if you don’t watch out.
While checking out the code using the Reflector I found out that the indexer on the SPListCollection uses internal methods to find out if a list exists or not which does not involve exception throwing. The exception is only thrown when we poor developers use the APIs. Inside the SPListCollection object is an internal method called GetListByName which works just like the indexer, but has a second boolean parameter which can be used to tell the method if we want an exception to be thrown when not found or just return null. If we were allowed to use this method, then our sample would look like this:
// -- Check if list exists.
SPList list = web.GetListByName("MSDN Tasks", false);
if(list == null)
{
...
}
Wow, now we could make some real use of this in high performance required scenarios – no exception handling involved.
The request…
To get this to work, all the SharePoint Development Team has to do is to make this method public! Please! I think it would be a great idea to go through the API’s of SharePoint and check these kind of things out.
This is by no means the only sample of code that easily can be made more efficient for us developers (outside of Redmond).
Technorati tags:
SharePoint,
WSS,
MOSS
