Should you define a null/unknown value for Java enums?

Question

When you define an enum for something that can be "undefined" in your interfaces, should you

• define a separate enum value for that, or
• just use enumValue = null for those situations?

For example,

serviceX.setPrice(Price priceEnum)

enum Price {  CHEAP, EXPENSIVE, VERRRY_EXPENSIVE, UNKNOWN } 

and priceEnum.UNKNOWN when needed

or

enum Price {  CHEAP, EXPENSIVE, VERRRY_EXPENSIVE } 

and priceEnum = null when needed?

Having a little debate on this. Some points that come to mind:

• using Price.UNKNOWN saves some "if (price == null)" code. You can handle Price x's all values in a single switch-case
• Depending on view technology, it may be easier to localize Price.UNKNOWN
• 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
• 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?
• 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(?)

Answer 1

This is actually an example of applying Null Object pattern. IMHO it is always better to have a dummy object rather than null. For instance you can add dummy methods to null-object rather than scattering your code with null-checks all over the place. Very convenient.

Also the name of the enum gives you some additional semantics: is the price unknown, undefined, not trustworthy, not yet known? And what does it mean if the price is null?

UPDATE: As Aaron Digulla points out, Null Object pattern requires memory. But this isn't actually the case most of the time. In the traditional implementation you typically have a singleton for Null object used everywhere as there is no need for separate instances. It gets even better with enums because you get singleton semantics for free.

Another point is that null reference and reference to some object occupy the same amount of memory (say 4 bytes on 32-bit machine). It is the object being referenced that occupies some extra memory. But if this is a singleton, there is practically no memory overhead here.

Answer 2

I'd say go with Price.UNKNOWN if that's a valid value for a price.

I agree with the drawbacks of dealing with null references that you mention, and I think they motivate the decision enough.

New languages, take Scala for example (and some older ones, Haskell) strain away from null references all together and uses option / maybe monads instead... for good reasons.