Skip to main content.
home | support | download

Back to List Archive

Re: Change in way undefined properties are handled

From: Peter Karman <karman(at)not-real.cray.com>
Date: Thu Jan 15 2004 - 01:08:09 GMT
Bill Moseley waxed lyrical on 1/14/04 6:26 PM:

> Yes, that (null).  Now I remember why it's there and I'm not sure what
> the best solution is -- not that it's a huge problem.
> 
> Basically, this returns an error (badprop is a property that's not
> defined in the index):
> 
>     swish-e -w foo -p badprop
> 
> but this doesn't (it returns "(null)" for the badprop).
> 
>     swish-e -w foo -x '<swishdocpath>\t<badprop>\n'
> 
> The reason that was like that was it's a bit hard to generate an error
> mid-way through the processing of the -x format string.  Yes, that -x
> string is parsed for every result.  If I generate an error swish.cgi
> then generates a lot of warnings and things don't get parsed correctly
> from the pipe.  That (null) is not that much of a problem, I think, and
> it makes parsing the results very simple.
> 

how hard would it be to parse the -x string prior to the search, to make 
sure it is valid for the particular index? I don't know if it's worth it 
if the (null) isn't that big a problem.



> The idea is that if you request a property name that is not defined when
> indexing then something is really wrong -- and that should be an
> exception.


I see your point. Calling a function with an illegal parameter merits a 
croak(), like passing a hash reference to a function when the function 
expects a simple scalar.

pek

-- 
Peter Karman - Software Publications Engineer - Cray Inc
phone: 651-605-9009 - mailto:karman@cray.com
Received on Thu Jan 15 01:08:17 2004