Skip to main content.
home | support | download

Back to List Archive

Re: Change in way undefined properties are handled

From: Peter Karman <karman(at)>
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.


Peter Karman - Software Publications Engineer - Cray Inc
phone: 651-605-9009 -
Received on Thu Jan 15 01:08:17 2004