One of the things I love about my job is that satisfying feeling of accomplishment that I get when I solve one of SharePoint’s quirky difficulties. If it weren’t for this feeling of euphoria that comes along every so often, I’d have gone insane long ago. Thankfully, SharePoint has no shortage of strange behavior and head-scratching moments.
One of my colleagues recently ran into a strange error while developing a custom Application Page. No matter how he was catching and handling runtime errors, every time an exception was raised during the Page Load event, the page would crash, displaying a perplexing error message and stack trace.
Specifically, he’d receive a “No item exists at
At this point, I thought of something. The page was utilizing query string parameters to receive data and pass data to itself across postbacks, so perhaps something was wrong with one of the parameters? I noticed one of the parameters he was using was named “ID”. I suggested we change the name of this parameter to something else, and lo and behold, the problem was solved.
For reasons I still don’t quite understand, although it does sort of make sense, the “ID” query string parameter is a reserved keyword in SharePoint. Any time this parameter is present, SharePoint tries to do something internally, which sometimes makes it take a crap. Oddly enough, the problem only happens when an exception is raised during code execution, regardless of error handling. The moral of this story is to NEVER use a query string parameter named “ID” while developing for SharePoint.
There are several other query string parameters one should not use as well, and most (but not all) of them are far more obvious than the ambiguously-named “ID” parameter:
(Thanks to Stefan Goßner over at TechNet Blogs for this list.)