One thing that helps with three-value logic is to insist that all conditionals ultimately have to boil down to just true or false, even if they are using the third value in it. This is the case in C#, which implements three-value using nullable bools. So e.g. if you have this:

    bool? t = true;
    bool? f = false;
    bool? u = null; // "unknown"

Then you can do things like (t & u) or (f | u) or (!u), and it works as you'd expect. But you can't write:

    if (t & u) ...

for example, because "if" requires a definite true or false. So e.g. if you want it to execute only if your expression is definitely true, you do:

    if ((t & u) == true) ...

etc. Consequently, you don't get silent bugs because a null slips through somewhere - if your expression ends up introducing nulls at some point, you always have to decide what exactly it means for it to be null at the end of the pipeline.

Coincidentally, it also doesn't allow (t && u) or (f || u), for the same reason why it doesn't allow "if" - because the operators are short-circuited, and whether the second operand is evaluated or not has observable side effects, so null/unknown cannot be handled safely.

In SQL, on the other hand, the use of NULL is a conditional implicitly does what I did explicitly above - i.e. NULL is basically treated as FALSE - which IMO is wrong in principle, but more importantly, results in silent, hard to detect bugs.