SharePoint online has really limited availability for error logging built in. Most of the time you have to throw the exception to either standard output, a list, or if it is a provider hosted application using a local text file. None of these options is terrible attractive since SharePoint already has logging availability in the ULS and a lot of fancy tools that allow relevant parsing to occur.
Using the ULS off premise isn’t really as easier as it is on premise (shocker). To do it, firstly, you have to make the relevant service reference. This is located here:
Once you have that, if you are deploying a generic service application remember to go to your settings page and add some logic in order to look up the current URL using a dynamic reference. If not, then you are almost there, it is helpful to push this logic to some sort of static method if you are using it for broad scope exception handling, but the meat is in the SendClientScriptErrorReport method. You can find this off the diagnostic object, this will depend on how you qualify it however (i.e. a top level alias directive). The method itself will take the form:
proxy.SendClientScriptErrorReport(“message”, “filename”, “line number”, “client”, “stack”, “team”, “filename);
This one took me a little bit to understand. Sometimes the Moles exception handling is so aggressive that it becomes a little tricky to understand exactly what is bubbling up.
Assume MethodX() is a member of base class ConcreteX. Requirements state that you need to have moles for MethodX() in order to support data mocking. It is important to remember for this particular requirement that base member access is achieved by allocating the mole type of ConcreteX and passing the instance in the constructor. This looks like the following:
ConcreteX x = new ConcreteX();
Now, if it isn’t done in this fashion MethodX() will not be moled, however you can still mole the entire assembly I suppose. However, doing it in the above fashion avoids using a wrapper in partial classes and a lot of rework based on class hierarchy.
The QueryService.QueryEx method is pretty useful in custom applications that leverage the inbuilt query features of SharePoint since it provides a System.Data.DataSet object containing a System.Data.DataTable object for each search result set, so can contain multiple result sets. Usually people use it to build custom views of mined data ala the search features, its utility is noticeable in it’s ease.
After migrating a pre-production SharePoint 2007 instance to 2010, my current client pointed out that one of their custom WebParts that make use of the QueryEx method was not functioning and bubbling up a System.ServiceModel.FaultException.
Looking at the ULS logs, I saw the following error being thrown:
Exception caught in QueryService class. Exception message: Exception from HRESULT: 0x80040E01. Stack: Server stack trace: at System.ServiceModel.Channels.ServiceChannel.ThrowIfFaultUnderstood(Message reply, MessageFault fault, String action, MessageVersion version, FaultConverter faultConverter) at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc) at
Microsoft.Office.Server.Search.Query.QueryService.DoQuery(QueryMethod queryMethod, String queryXml, String& domain, String& queryId, Int32& startAt, Boolean& fStandardResults, StringCollection& querySuggestions) at Microsoft.Office.Server.Search.Query.QueryService.QueryEx(String queryXml).
If you get this error (it should be noted that you can get a similar error when working with the FullTextSqlQueryclass as well, you must reduce the RowLimit in the query. It should be noted that the RowLimit ceiling is 917728059 and you should not use MaxValue.