Thank you for the detailed explanation. I will refactor my code to
store the results so that it is not making any assumptions about the
semantics of the Element() method.
Serge Baltic wrote:
>> The code builds with no errors or warnings.
Null reference problems are not detected by the C# compiler neither as
errors nor as warnings.
>> testing for null would remove the possibility of the null
Consider the following code:
if(Console.ReadLine().Length >= 3)
str = Console.ReadLine().Substring(0, 3);
We could suppose that testing for length of three chars or above would
remove the possibility of an "index out of range" exception in the
second line. Luckily we know the semantic of the ReadLine method and
would rather store its value in a variable in any reallife code.
From the formal point of view, your sample is quite similar: ReSharper
does not know the semantics of the Element method, so it cannot assume
the method result does not change in time. Hence the warning.
Here we do not consider any threading issues (by convention, null
reference analysis assumes non-reentrant single-threaded execution and
relies on users' thread safety precautions -- otherwise there'd be
tons of false alerts in simple code), but just the nature of the
method, in that it could behave ReadLine()-like.
Should this method be a property with parameter (smth like
root.Element["Dealer"]), ReSharper would have assumed this code
nullref-safe, because that's what makes the difference between
property semantics and method semantics. So sad properties with
parameters were dropped from C#.
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”