0

I have hit multiple cases that seem to be a pattern:

Contract.Ensures(Contract.Result<BlahType>() != null);
...
BlahType Blah = new BlahType();
...
...
return Blah;

and it gripes.

In all cases the field is private and nothing else in the method messes with it. (These are all lazy initializations as the data must come from the disk.)

Of course I could add a Contract.Assume here but I don't like that kind of answer.

Loren Pechtel
  • 8,945
  • 3
  • 33
  • 45
  • 3
    Full (minimal) code causing behavior? –  Jul 25 '12 at 20:41
  • 1
    I can't reproduce this with the code you've provided, are you sure nothing else is modifying `Blah`? – Peter Ritchie Jul 25 '12 at 20:48
  • I haven't worked with the code contracts framework, but you mention you're using a private field. Is that possibly the answer? Perhaps it's taking a more aggressive approach to it as theoretically threaded access might reassign the field to null? What if you tried using a local variable (which is then assigned to the field) and return that? – Chris Sinclair Jul 25 '12 at 21:10
  • @ChrisSinclair: CC never considers threading issues – porges Jul 26 '12 at 01:15

1 Answers1

0

The only way you can convince the static checker that a field is never null (or any other condition) is by making that an invariant. The invariants in the invariant method are checked at the return of every method in your class, so the checker may assume they hold. So, add to the bottom of your class:

#region Invariants
[ContractInvariantMethod]
[System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Performance",
    "CA1822:MarkMembersAsStatic",
    Justification = "Required for code contracts.")]
private void ObjectInvariant()
{
    Contract.Invariant(this.blah != null);
}
#endregion

Notes:

  • The invariant method is any private void method with no arguments that has the ContractInvariantMethod attribute applied to it. You can put multiple invariants in there.
  • To quickly get an ObjectInvariant method snippet, type cimTABTAB.
  • Other Code Contracts snippets can be found here.
  • In C#, private/protected fields and local variables are written with the first letter of the identifier in lowercase (Camel case). See here for more information. This makes your code more readable and understandable.
Daniel A.A. Pelsmaeker
  • 47,471
  • 20
  • 111
  • 157
  • Across an object I would agree with you, but this is within a method. Are you saying the static checker can't see that nothing the routine calls could mess with it? – Loren Pechtel Jul 27 '12 at 16:50
  • You were talking about a (private) field, so this is what I could come up with for a field. But you are apparently talking about a local variable, something entirely different. Could you add to your post more code/context that might indicate the problem? With the code you've shown I cannot reproduce your issue. My static checker does not complain. – Daniel A.A. Pelsmaeker Jul 27 '12 at 19:41
  • Can you explain why you need to suppress CA1822 when the method access `this.blah`? I have encountered this too, but don't see why. – Ergwun Apr 14 '16 at 11:54
  • 1
    Never mind - I've just realized that it's because code analysis operates on the IL, which has been re-written to the remove the method body. – Ergwun Apr 14 '16 at 12:34