Nullable enumeration values vs. “NoValue” or “Undefined”, etc

Question

I often write code which translates entities in the database to domain objects. These entities often have fields which are constrained and translate to enumerations in the domain objects. In some cases, though, the fields can be null.

For example, imagine I have a PrintJob entity with a Status field that can be New, Submitted, or Completed and a Result field that can be Succeeded, FailedNoPaper, or FailedNoToner but it can also be NULL if the Status is not Completed.

On the one hand, I like having a one-to-one mapping of entity field values to domain object enum values, but on the other hand, it somehow feels "better" to always have values for properties with enumeration types.

My question is: is it better to represent the value of the Result field in my domain object as a nullable value (e.g. MyStatus? in C# or VB.NET) having essentially no value when the corresponding entity field is NULL, or should I create a special enum value along with the others, e.g. NoValue or Undefined?

Answer 1

If a field value is one of a list of predefined values, your domain will have a real-world value that you can correspond to NULL. All you have to do is look for it. If the Status is not completed its result could be 'NotFinished', 'Unavailable', 'DoesNotExist' or 'Unknown'.

Think about this in a non-code way. If you print something and ask a colleague to bring over the stack of papers from the printer, how would he let you know that there is no printout on the printer? He might say it isn't finished yet, it wasn't available yet, there was nothing on the printer...

As far as enums go, I'm not a big fan of nullable enums. Add a single, default field such as 'Unknown' and you NEVER EVER have to worry about it being NULL. Otherwise, you will spend reams of code in your application to first check for NULL before doing anything sensible... Enums, like booleans, should shy away from being NULL.

Answer 2

Looking at this as a state machine problem, where each state was represented by an enum, it would be reasonable to provide an enum for all states, including the "not yet" state. I'd be tempted to name it something meaningful, though, like "PROCESSING" rather than a synonym for "NULL".

Setting aside the programmatic problems with NULL, representing the state as NULL would be a valid way to say "no state at all". But putting the second value into some known initial state is more definitive.

Answer 3

Compare your situation to the empty string / null string:

An empty string (in C: '\0') means the string is known to have no value, whereas the null string means it is not known to have a value.

As the result value is not known until the job finishes, the null value seems correct. Of course you can use an enum value to indicate "not known to be known". It also means you cannot query the result value until you have checked the status is "completed".