title: null objects vs. empty objects
body: <p>[ This is a result of <a href="https://stackoverflow.com/questions/1626597/best-practice-should-functions-return-null-or-an-empty-object">Best Practice: Should functions return null or an empty object?</a> but I'm trying to be very general. ]</p>
  
  <p>In a lot of legacy (um...production) C++ code that I've seen, there is a tendency to write <strong>a lot</strong> of <em>NULL</em> (or similar) checks to test pointers.  Many of these get added near the end of a release cycle when adding a <em>NULL</em>-check provides a quick fix to a crash caused by the pointer dereference--and there isn't a lot of time to investigate.</p>
  
  <p>To combat this, I started to write code that took a (<code>const</code>) reference parameter instead of the (much) more common technique of passing a pointer.  No pointer, no desire to check for <em>NULL</em> (ignoring the corner case of actually having a null reference).</p>
  
  <p>In C#, the same C++ "problem" is present: the desire to check every unknown reference against <code>null</code> (<code>ArgumentNullException</code>) and to quickly fix <code>NullReferenceException</code>s by adding a <code>null</code> check.</p>
  
  <p>It seems to me, one way to prevent this is to avoid null objects in the first place by using empty objects (<code>String.Empty</code>, <code>EventArgs.Empty</code>) instead.  Another would be to throw an exception rather than return <code>null</code>.</p>
  
  <p>I'm just starting to learn F#, but it appears there are far fewer null objects in that enviroment.  So maybe you don't really have to have a lot of <code>null</code> references floating around?</p>
  
  <p>Am I barking up the wrong tree here?  </p>