I ran into those nullpointerexceptions a few time during my last stint with the .NET lib. I switched back to the self-built lib as usual to see what's going on and it turns out I was sending null values for objectId and the lib was running operations on it and crashed.
I think the public constructors that take objectIds, aliases and the like should do the input checking and not simply perform operations on those strings. Let's take the CallHandler class as an example. It's public constructor does this:
//if the user passed in a specific ObjectId or display name then go load that handler up, otherwise just return an empty instance.
if ((pObjectId.Length == 0) & (pDisplayName.Length==0)) return;
Pass null and you're out with an exception. Then in the GetCallHandler method, the input is actually checked
//when fetching a handler use the query construct in both cases so the XML parsing is identical
if (!string.IsNullOrEmpty(pObjectId))
{ .... }
else if (!string.IsNullOrEmpty(pDisplayName))
{
strUrl = string.Format("{0}handlers/callhandlers/?query=(DisplayName is {1})", HomeServer.BaseUrl, pDisplayName.UriSafe());
}
else
{
return new WebCallResult
{
Success = false,
ErrorText = "No value for ObjectId or Alias passed to GetCallHandler."
};
}
I think it should be the other way round.. check input in the public methods, and then in the private, you can assume the values are correct since nobody but you gets to call them - being private and all.
Since the contructor returns no WebCallResult, an ArgumentException seems to be the most likely candidate when input that must not be null is actually null.
