An Unexpected Error has occurred or Value cannot be null. Parameter name: input.

‚ÄčThis error quite commonly turns up as the dreaded "An unexpected error has occurred", which to a SharePoint practitioner is anything but unexpected. In fact that is the most common form in this scenario, but because the error message is so universal I thought I had better qualify it by referring to the other manifestation.

I have been caught out by this one a couple of times, once using a query string parameter "Title" and then a couple of years later falling into the same trap with "ID".

The "Title" fiasco was actually with this site. If you look at the URL of this page you will see that the actual page name is a constant for all the pages discussing error pages. The page is fixed and the content is inserted when the page is requested according to the query string parameter. That's the cheap-and-cheerful publishing model you might use if, like me, you were too mean to stump up for a SharePoint Server licence and do content management properly.

You may have noticed that the query string parameter was called "name", and it is a key into the SharePoint list containing the various error messages and their explanations. Well, that parameter was originally called "Title" and bad things would happen occasionally. Everything works okay for the anonymous user, but sometimes when you browse to the page as an authenticated user, and always when you try to save after editing the page, you get the nasty errors. If you ignore the error and re-load the page you may well find that the edits were saved anyway, phew! But it is pretty disconcerting nonetheless.

You won't find anything useful in the ULS that is helpful - just a null reference exception. You breakpoint all your custom code but it never gets hit. The error may be intermittent - sometimes only if you edit the page. But you never see it as an anonymous user (or at least I haven't). You can edit the page okay if you strip off the query string parameter - Hmmm.

So what is going on here? Well, the problem is the choice of query string parameter name, because SharePoint has already bagged a few, and that includes some of the ones that are the first to come to mind, like "ID" and "Title" and "List" and "Type". I am not sure if it messes up the SPContext or just upsets the JavaScript somehow, but it seems to be associated with the ribbon control judging from the fact that anonymous users seem to be unaffected.

So if you are going to use query string parameters, I recommend that you avoid choosing the following names (list provided by Stefan Gossner):