Previous | Next
Topic: utAssert.eq Does not handle NULLs correctly
Conf: 537, Msg: 43118
From: Jay Bundy (jay.bundy@lexis-nexis.com)
Date: 6/20/01 06:48 AM
utAssert.eq Does not handle NULLs correctly Jay Bundy jaybundy jay.bundy@lexis-nexis.com
1.Okay, I don't know what p.I is, and assume everybody knows how NULL works in logic, but for those who don't, here's my understanding of it. Tell me if you think this is wrong, and I'll produce a list of outputs for all combinations. NULL is considered a third value of undetermined state, so it is NIETHER TRUE nor FALSE.
([anything] OR TRUE) evaluates to TRUE, because in the case of OR, the TRUE in the right side is sufficient to determine a TRUE result.
In the case of (NULL OR FALSE), since the second value is false, the whole statement depends on the first value, which is unknown, hence the whole statement evaluates to NULL (unknown).
([anything] AND FALSE) would evaluate to FALSE, because the FALSE is sufficient to determine the result.
Likewise, (NULL AND TRUE) would still be NULL, as the result now depends on the left hand operand, which is unknown.
2. My concern is not with the 'this' procedure, but with 'eq'. If both input values are NULL then it certainly results in a 'success', which seems okay to me. The problem is that it passes (check_this_in = against_this_in) to the 'this' procedure. If EITHER of these (or both) is NULL, then the equals operator evaluates to NULL and this is considered a perfectly valid result to 'this', which treats it as a passed assertion.
But when I call 'eq', I would not expect to check a specific populated value (like 'c') against a NULL and get a 'success' test result. I would expect (and want) that to fail. The reason for this is that when I do a test for equality, I want anything other than the two values being equal or both NULL to be a failure.
This is not the current behavior of 'eq'. If this is an intended behavior then I've made a mistake and this is not a bug, but rather I would suggest that the behavior be changed to fail under the above circumstances.
This would make sense to me, since in SQL, rows don't get returned for NULL comparison results in the WHERE clause (like equals), and branches and loops are entered ONLY on TRUE conditions (not NULL).
Have I misunderstood something?