A null operand that is an error (D-103, was D-103).
Every operator gives null when an operand is null, and the question of D-103 is whether that is a
mistake of the expression (a diagnostic, which stops a strict run) or only missing data (nothing is
reported). The specification does not say, and the TCK's flag errorResult is the evidence:
The operand is null | The result is | TCK |
|---|---|---|
of + - * / ** and -x, whatever the other operand is | null with :null_operand | all 125 cases of 0100 with a null are flagged |
of <= and >=, so of between and of a closed range (null between 1 and 10, 5 in [1..null]) | null with :null_operand | 0071#null_001 to #null_003, 0072#null_001, #null_001_c, #null_001_d are flagged |
of < and >, so of an open end of a range (5 in (null..10]) | a plain null | 0072#null_001_a and #null_001_b are not |
of and, or and not | a plain null | 0064, 0065, 0066#003_a are not |
= and != | never null (Table 50) |
The difference between the inclusive and the strict comparison has no reason in the specification: it is
what the cases of the TCK have, all of them, and nothing else has a case. error/1 is the one place that
makes the error, and Feel.Runtime.Compare is the one that says for which comparisons.
Summary
Functions
The outcome of an operator that is given a null: null, with the error.
Functions
@spec error(String.t()) :: {:error, Feel.Diagnostic.t()}
The outcome of an operator that is given a null: null, with the error.
iex> {:error, diagnostic} = Feel.Runtime.NullOperand.error("+")
iex> {diagnostic.code, diagnostic.message}
{:null_operand, "an operand of + is null"}