Web.GetListItem with a non list URL breaks SPContext

Question

We have a bit of a weird issue and i was wondering if anyone had any insight on why the issue was occurring.

We have a page deployed into the SharePoint root which has a custom webpart which would normally be deployed onto a page in a document library. Inside this webpart we call SPContext.Current.Web.GetListItem(Page.Request.Url.OriginalString) to find some details that would normally be associated with the hosting page. In the case where we have this webpart on the page in root we dont care about this extra data, so we have this code

try
{
    // 1
    SPContext.Current.Web.GetListItem(Page.Request.Url.OriginalString);
    //do some stuff with the list item
}
catch{ /*2*/  /* Swallow any exceptions as we dont really care*/ }

However we were noticing that after swallowing the exception here SPContext is badly broken.

For example if we call SPContext.Current.Web.Lists.Count at point 2 we get back 0 (IE there are no more lists on the context)

If we call SPContext.Current.Web.Lists.Count at point 1 we get back a whole lot of lists as expected.

If we call SPContext.Current.Web.Lists.Count at both point 1 and point 2 we get back the correct number of lists at both locations.

I would like to know why this happens (we have a work around for this issue that avoids the problem but really want to understand what is breaking in the context when this happens).

A couple of things to note:

• We have only observed this issue when running as users other than SYSTEM
• When we touch SPContext.Current.Web.Lists before triggering the exception things seem to work ok

Answer 1

I'm wondering if you aren't actually suffering from the pretty well-known problem as described by Waldek (http://blog.mastykarz.nl/inconvenient-spweb-getlistitem-exception-hresult-0x80070001/) which is due to the way the GetListItem is implemented and the URL that receives as parameter.

For the 2nd problem (where you attempt using the SPContext after exception being raised) - is actually quite normal as many properties most likely are not properly setup, which (if you launch debugger) might generate exceptions themselves when calling them.

As with regards to security - make sure you do use the RunWithElevatedPrivileges if you plan to execute operations which should work irelevant of the user permissions.