bkoelman
commented
8 years ago Thanks for bringing this to my attention.
Resharper runs its nullability analysis engine to determine whether to suggest the "Not Null" and "Can Be Null" context menu options. Part of that analysis is looking into the target method call stack, to see if any code paths exist that return null. That makes it much smarter than suggestions from ResharperCodeContractNullability. Resharper's engine stops at assembly boundaries. To get stable results, you need to add a class library to your project to get them. In this case, however, they are never offered for nullable value types.
Although ((int?)null).ToString() will not throw, someNullable.Value will. A warning in such cases is still valuable.
It may be helpful when overriding a third party class that returns a nullable value, to annotate that with [NotNull] if the overriden behavior never returns null.
My testing shows that adding [NotNull] produces extra checks. For example, when the implementation of a method returns null while it has a [NotNull] return annotation:
Furthermore, it looks like [CanBeNull] on a nullable return value has the same effect as omitting the attribute.
But... adding NotNull is not entirely consistent. Resharper warns on a null comparison only in the first case:
So many inconsistencies.... I'm not sure what the right approach is here.
starkcolin
A nullability warning (RNUL) on an object of type Nullable is redundant.
This is consistent with ReSharper's own nullability analysis - there is no context menu command available to annotate a Nullable with either NotNull or CanBeNull.
Something like
((int?)null).ToString()will not throw a NullReferenceException, so there is no benefit to having a CanBeNull annotation. A NotNull annotation does not seem logical either on a variable of type int?.Unless there is a specific benefit to having a NotNull/CanBeNull annotation on a Nullable that I'm not thinking of, I propose that the warning should not be displayed for objects of this type.