The result of the predicate can be either TRUE, FALSE, or UNKNOWN, depending on the presence of NULLs.
If the predicate evaluates to UNKNOWN, then the constraint is not violated and the row can be inserted or updated in the table.
[1] Most database management systems restrict check constraints to a single row, with access to constants and deterministic functions, but not to data in other tables, or to data invisible to the current transaction because of transaction isolation.
Some examples of dangerous constraints include: User-defined triggers can be used to work around these restrictions.
Although similar in implementation, it is semantically clear that triggers will only be fired when the table is directly modified, and that it is the designer's responsibility to handle indirect, important changes in other tables; constraints on the other hand are intended to be "true at all times" regardless of the user's actions or the designer's lack of foresight.