title: Intended or less-wrong pattern for using non-nullable types of class properties
body: <p>There's a great question here about nullable types:</p>
  <p><a href="https://stackoverflow.com/questions/67505347/non-nullable-property-must-contain-a-non-null-value-when-exiting-constructor-co">Non-nullable property must contain a non-null value when exiting constructor. Consider declaring the property as nullable</a></p>
  <p>Which has some great ways to overcome the warning, but I'm interested in the reasoning behind using any particular method.</p>
  <p>I'm working with EF Core to craft an API. I'm being careful to never instantiate a model class without having the correct data, but the class doesn't know that so we get the typical &quot;Non-nullable property must contain...&quot; warning.</p>
  <p>At least in my head, I <em>want</em> the null reference error to happen when appropriate, to be passed back to a client or to prevent inappropriately null/empty values being passed down.</p>
  <p><strong>Example:</strong> a &quot;this field required situation&quot;, if it somehow gets past the front-end validation an exception should be thrown, and the exception handler returns an appropriate BadRequest response to the client. I'm currently doing this rather than handling each individual property with an explicit validation method, at least for required properties.</p>
  <p>It's seems disingenuous to try to accommodate the possibility of a null being passed in by:</p>
  <ul>
  <li>Declaring the property nullable: this property really shouldn't be nullable, so I would just be allowing it in order to suppress the warning, which may cause functional issues or extraneous considerations elsewhere.</li>
  <li>Setting a null-forgiveness <code>null!</code>: which seems appropriate in some situations, but not anywhere where the property should be set and not-null at all times.</li>
  <li>Setting a default such as <code>string.Empty</code>: again appropriate in some situations, but not where the property should be set to something substantial and meaningful.</li>
  <li>Setting up a constructor: this seems a lot of extra work to do essentially the same thing, and I'm not certain this overcomes the warning as much as moves it.</li>
  </ul>
  <ol>
  <li>Am I wrong in wanting to use an exception to catch when an instantiation doesn't set or sets null a non-nullable property? I only question this because of the warning about the non-nullable property.</li>
  <li>Is there some other pattern I'm unaware of that would be more appropriate, and that's why the warning?</li>
  <li>Am I just putting too much stock in the warning?</li>
  </ol>