# `Feel.Runtime.NullOperand`
[🔗](https://github.com/FeeJai/BDM/blob/feel-v0.1.0/apps/feel/lib/feel/runtime/null_operand.ex#L1)

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.

# `error`

```elixir
@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"}

---

*Consult [api-reference.md](api-reference.md) for complete listing*