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: Wed Jan 14 2004 - 23:12:12 GMT
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)"
> For the C API the caller will be expected to check for errors after the
> call, but the program will not abort.  This is similar to the current
> behavior, although currently no error is returned other than a NULL
> (which indicates an invalid property name).
> For the SWISH::API module, which currently just returns the undefined
> value, I think the correct thing to do is croak() -- which is what the
> binary would do.
> That change to SWISH::API could cause some existing uses to break,
> although croak()ing will produce a better message than that "(NULL)"
> string.

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').

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).

But perhaps I am missing your strategy here?

> Second Problem:  Undefined property values
> Here's where the current design is really broken, but fixing it will
> likely cause problems (when using SWISH::API).

> For the SWISH::API module, undefined values will return undefined.
> I'll have to update swish.cgi to not generate warnings
> when trying to print undefined values.

makes sense to me that the Perl functions would return 'undef' for 
undefined values.


Peter Karman - Software Publications Engineer - Cray Inc
phone: 651-605-9009 -
Received on Wed Jan 14 23:13:01 2004