While debugging some custom SharePoint code (not written by me, mind you) today I ran in to this little gem:
Cannot complete this action.
Please try again. at Microsoft.SharePoint.Library.SPRequest.MapUrlToListAndView(String bstrUrl, String bstrUrlToMap, Guid& pgListId, Guid& pgViewId)
at Microsoft.SharePoint.SPWeb.GetListFromWebPartPageUrl(String pageUrl)
at Microsoft.SharePoint.SPWeb.GetListFromUrl(String pageUrl)
at MyWebPart.EventCalendars.EventCalendars.GetCalendarUrl(Uri current, Uri referrerUri)
at MyWebPart.EventCalendars.EventCalendars.CreateChildControls()
Microsoft is a multi-billion dollar company. And yet, with all their resources, training, skills and expertise, they still produce an error message that says the equivalent of “I’m broken. Try pressing F5 and see if I am not broken in a few seconds.”
Is it really that the developers of the SPRequest object in this case don’t actually know what went wrong, so they bubble up this shoulder shrug?
Or is it that they do know what went wrong, but are embarrassed by it? Disgusted by it? Too polite to throw another team under the bus publicly by immortalizing them in an Exception message?
Who knows.
Consequences
When a developer encounters a message like this, the clock begins to tick while a solution is sought out. With few clues as to what went wrong, that developer has to do more work to find a suitable repair. More work means more time, more cost, more risk in the project.
Microsoft can be blamed for project overruns, but they can’t be held directly responsible. Still, as a standard bearer for the industry, I think they have an obligation to demonstrate the kinds of best practices they advocate. This error message fails that test with great glory.
We can do better
The takeaway lesson here is obviously that if you or your company is creating a consumable API, provide useful feedback. There’s a little bit of the Golden Rule tied up in this as well – write exception messages for others the way you’d want them to write a message for you.
Leave a Reply