On Wed, Jan 14, 2004 at 05:09:54PM -0600, Peter Karman wrote:
> 
> 
> Bill Moseley waxed lyrical on 1/13/04 11:48 AM:
> 
> >
> >I'm also interested in feedback from any Perl (SWISH::API) users.
> >
> >First problem:  the "(NULL)"

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.

> not sure why croak() is a better option here. That seems more drastic 
> than the corresponding response in the C API. Or perhaps I don't 
> understand croak() as well. I thought it was similar to die() but gave a 
> more helpful error (particularly with respect to line numbers) when 
> called within a module (or package other than 'main').

croak() is just calling die in the xs code.  

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.  So in most cases if you have a typo in the property you
will want the program to abort.  Again, minor problem because that kind
of error will be obvious regardless (as in missing text).

Anyway, in SWISH::API calling:

    $result->Property( "propfoo" )

either returns the data or undefined if that result doesn't have a value
for that property.  The exception is if "propfoo" is just a bad name,
and that throws an exception.

That's the correct way to do things, really.  And to catch that problem
it's more noise in the code to do:

    my $prop = $result->Property( "badprop" );
    if ( $swish->Error ) {
        deal with it
    }

than doing this:

    eval { process_request() }
    if ( @_ ) {
       deal with it
    }
        
Then later in your code all you have to do is:

   $prop = $result->Property( "badprop" );

and the exception will be caught at a higher level.

If you expect that you could have bad prop names and don't care all you
do is:

   eval { $prop => $result->Property( "badprop" ) };

and ignore the problem.  But it's nice to have a way to catch exceptions
higher up in the code nesting.

> I'd rather see SWISH::API set the Error value (as in $handle->Error) or 
> something similar. That way we can check for the error and act 
> accordingly (as in the C API).

Calling die() like the above allows you to do it that way.


Still, there's still this method:

   $prop_string = $result->ResultPropertyStr( "foo" )

and that returns empty string for blank values and "(null)" on bad
property names.  But the $result->Property() method is more low-level.

Thanks for the feedback.

-- 
Bill Moseley
moseley@hank.org