title: Should you define a null/unknown value for Java enums?
body: <p>When you define an enum for something that can be "undefined" in your interfaces, should you </p>
  
  <ul>
  <li>define a separate enum value for that, or </li>
  <li>just use enumValue = null for those situations?  </li>
  </ul>
  
  <p>For example,</p>
  
  <p>serviceX.setPrice(Price priceEnum)</p>
  
  <pre><code>enum Price {
   CHEAP, EXPENSIVE, VERRRY_EXPENSIVE, UNKNOWN
  }
  </code></pre>
  
  <p>and priceEnum.UNKNOWN when needed</p>
  
  <p>or </p>
  
  <pre><code>enum Price {
   CHEAP, EXPENSIVE, VERRRY_EXPENSIVE
  }
  </code></pre>
  
  <p>and priceEnum = null when needed?</p>
  
  <p>Having a little debate on this. Some points that come to mind:</p>
  
  <ul>
  <li>using Price.UNKNOWN saves some "if (price == null)" code. You can handle Price x's all values in a single switch-case </li>
  <li>Depending on view technology, it may be easier to localize Price.UNKNOWN </li>
  <li>using Price.UNKNOWN kind of causes "magic number" problem in the code, IMO. Here we have Price.UNKNOWN, elsewhere maybe Color.UNDEFINED, Height.NULLVALUE, etc</li>
  <li>using priceValue = null is more uniform with how other data types are handled in Java. We have Integer i = null, DomainObject x = null, String s = null for unknown values as well, don't we?</li>
  <li>Price.UNKNOWN forces you to decide whether null value is allowed univerally for all use cases. We may have method Price getPrice() which may return Price.UNKNOWN and setPrice(Price p) which is not allowed to accept Price.UNKNOWN. Since Price.UNKNOWN is always included in the enum's values, those interfaces look a little unclean. I know priceValue = null has the same problem (you cannot define in the interface whether null is accepted or not) but it feels a little cleaner and a little less misleading(?)</li>
  </ul>