2 ms·
It is not possible to have a NULL type that works for all situations and has stable semantics. The issue is, NULL should be a concept, not a value. I see no pr
by prmph 8y ago
It is not possible to have a NULL type that works for all situations and has stable semantics.
The issue is, NULL should be a concept, not a value. I see no problem with using sentinel values, so long as they are well designed, and such good design comes with skill and experience, just as with all other aspects of architecture. The quest to have a single value that can be used for all the various possible meanings of NULL, to me, is the root of the problem.
- lisper 8y ago> The quest to have a single value that can be used for all the various possible meanings of NULL, to me, is the root of the problem. Exactly right. In particular, the conflation of nulls to indicate both error and non-error conditions (e.g. out-of-memory vs end-of-linked list) makes it impossible to distinguish errors from non-errors in many situations, and that is obviously bad. Ideally you want nulls/sentinels that carry information about where, when, and why they were generated. You want separate nulls for numerical overflow/underflow, end-of-linked-list, out-of-memory, timeout, suppressed error/exception, unpecified/unknown value (preferably a separate one for each type) yada yada yada.