When working with SharePoint errors in ULS logs, you can find the error message near to the stack trace. In case of simple methods the stack trace may be enough to identify the exact conditions under which the exception was thrown. However, if the method is complex, with a lot of conditions and branches, it is not always trivial to find the error source, as we don’t see the exception message itself, as it is stored in language-specific resource files, and you see only a kind of keyword in the code.
For example, let’s see the GetItemById method of the SPList object with this signature:
internal SPListItem GetItemById(string strId, int id, string strRootFolder, bool cacheRowsetAndId, string strViewFields, bool bDatesInUtc)
There is a condition near to the end of the method:
throw new ArgumentException(SPResource.GetString("CannotFindUser", new object));
throw new ArgumentException(SPResource.GetString("ItemGone", new object));
How could we “decode” this keyword to the real error message? It is easy to achieve using PowerShell.
For example, to get the error message for the “ItemGone”:
Item does not exist. It may have been deleted by another user.
Note, that since the second parameter is an empty array, we can simply ignore it when invoking the static GetString method.
If you need the language specific error message (for example, the German one):
$ci = New-Object System.Globalization.CultureInfo("de-de")
Das Element ist nicht vorhanden. Möglicherweise wurde es von einem anderen Benutzer gelöscht.
Having the error message, it is already obvious most of the time, at which line of code the exception was thrown.
It can also help to translate the localized message to the English one, and use it to look up a solution for the error on the Internet using your favorite search engine, as there are probably more results when you search for the English text.