[Jamey Cribbs <jcribbs / twmi.rr.com>, 2006-03-04 18.56 CET]
> However, the last example does give me an idea.  I'm going to take a 
> look at the KBTable#select method and see if I can wrap the query 
> processing logic in a begin/rescue block.  It may be as simple as what 
> David shows here, have the rescue return false.  The problem I can see 
> is when there is an OR condition in the block, i.e.:
> 
> #select { |r| r.speed > 300 or r.range < 900 }
[...]
> Now, lets say we are looping through the table records and we get to a 
> record where :speed is nil and :range is 800.  According to the query 
> block, this record should qualify as a valid match.  But, if I don't 
> override NilClass#method_missing to return fasle, but, instead, try to 
> catch it with a begin/rescue block like I show in the code above, the 
> record will *not* be added to valid matches.  The problem with the code 
> above is that I can't get granular enough.  There is no way to get 
> inside the query block and put a begin/rescue around *each* condition 
> within the block. 

But doesn't NULL always propagate in "database semantics"? I mean, if any
subexpression is NULL, the whole expression becomes NULL. It's the expected
behaviour (but maybe not to the users of KirbyBase). In SQL, normally, one
uses NVL(a, b) (with the meaning 'a.nil? ? b : a') to guard subexpressions
against NULL.