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 <url>. It may have been deleted or renamed by another user” error. What item? The one that the page isn’t using at all? Obviously. The corresponding stack trace wasn’t too helpful either. When stepping through the debugger, it was clear that the Page Load event was executing successfully, but the page was still crashing, even when the entire method was wrapped in a try/catch block with proper exception handling.
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.
The Moral of The Story
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.)