9

I read today about C# 4.0 code contracts. It seems like the common practice for validating a parameter to a method isn't null is as follows:

Contract.Requires(p != null);

However it seems quite unreasonable to me that I'd have to do this for every parameter of every interface method in my code. In the vast majority of cases, the parameters are expected not to be null. I'd expect there would be some sort of mechanism that allows defining some specific parameters are "allowed" to be null (similarly to the "@Nullable" annotation in Java), and that the Contracts framework will automatically ensure the rest aren't null.

Besides saving much time on this "boilerplate checks" (as well as many "Contracts classes", as many times there simply aren't any conditions to be verified except for non-null parameters), it'll also make the contracts code cleaner and more "logic-oriented".

My question is, is there any way to do this, and if not, where isn't there one, or possibly why is my approach here wrong?

user976850
  • 1,086
  • 3
  • 13
  • 25
  • It would have been useful, but there isn't any shorthand to do this because nobody has changed the language specification to provide one and then implemented it and released it. See Eric Lippert's reply to a similar question here: http://stackoverflow.com/questions/2806894/why-c-sharp-doesnt-implement-indexed-properties – Matthew Watson Mar 18 '13 at 07:20
  • You can use the `crn` snippet to automatically generate the boilerplate for these not-null statements, which reduces the typing a little. – Matthew Strawbridge Mar 31 '13 at 19:56

1 Answers1

0

I don't agree, null is very helpful when you need to check if something didn't initialized yet, or data was not found, and sometimes you'll want to pass null to a method and its fine, the code contracts are good for common methods that serves lots of classes, and for api definitions. If you write in a layered architecture you just need to protect the interactions between the layers, and you are null safe inside each layer.

your domain got nulls, and its ok.

Chen Kinnrot
  • 20,609
  • 17
  • 79
  • 141
  • You misunderstand him. He's asking why there isn't a shorthand for saying that a parameter isn't allowed to be null. – Matthew Watson Mar 18 '13 at 07:16
  • 1
    Sorry, what I should have said is: He's asking why nulls aren't disallowed by default, but with a shorthand for saying that a parameter *is* allowed to be null. He's definitely right that the normal case is that nulls are NOT allowed (at least, in my experience). – Matthew Watson Mar 18 '13 at 07:20
  • 2
    Yeah what I mean is, he's not asking for nulls to be completely disallowed - just for them to be disallowed *by default*, with a mechanism to allow them if necessary. – Matthew Watson Mar 18 '13 at 07:22
  • Just for the record: Tony Hoare, the guy who **invented** null references, believes it was a ["billion dollar mistake"](http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare). So I *guess* we should at least think twice before defending it too much. ;) – rsenna Sep 30 '14 at 19:19