[Mapserver-users] python mapscript

[Steve Lime]

MapServer query functions do return an error (MS_FAILURE) but also set
the error code to MS_NOTFOUND so that folks can trap that condition
specifically in their application. The CGI does that using the EMPTY web
parameter. Yes, you could change the return status to MS_SUCCESS, but
either way you'd have to examine the error code to see if no records
were found (or worse the result set itself). It seems more intuitive to
me to encourage that check by returning MS_FAILURE.

Steve

Stephen Lime
Data & Applications Manager

Minnesota DNR
500 Lafayette Road
St. Paul, MN 55155
651-297-2937

>>> Sean Gillies <sgillies at frii.com> 07/02/03 11:06AM >>>
Michael,

I think this is probably an issue with MapServer's C library.
Am looking into it now to see what happens in msQueryByPoint.
I agree that msQueryByPoint should not raise an error in the
case of no records found by an otherwise proper query.

Another thing we could do is to evade the error in MapScript's
error handler like we are doing with the error that is raised
when no shapefile tileindex is present.  Maybe this is the
best way for now, and push to change msQuery* behavior for
MapServer 4.1.

cheers,
Sean

On Wednesday, July 2, 2003, at 09:14  AM, Michael Schulz wrote:

> Hi,
>
> i have a question concerning the new error handling code in python
> mapscript. While it is very good that mapscript now throws real
> meaningful exceptions for a lot of errors, it is somewhat annyoing
that
> e.g. queryByPoint also gives an error when no records where found.
What
> would be the correct way to change this behaviour?
> A bit more background information why this behaviour is annoying me 
> (for
> those using python mapscript in the zmapserver environment): i am
> working on implementing query mechanisms in zmapserver, and in the
> combination zope-zmapserver-python/mapscript it seems, that i am not
> able to catch this exception correctly. Even worse, the zope process
> gets killed (although an error should be raised, the zope process
> segfaults). Well, as you might assume this is not the intended
> behaviour. Hmm, any ideas, where to start looking?
>
> TIA, Michael
>
--
Sean Gillies
sgillies at frii dot com
http://www.frii.com/~sgillies 

_______________________________________________
Mapserver-users mailing list
Mapserver-users at lists.gis.umn.edu 
http://lists.gis.umn.edu/mailman/listinfo/mapserver-users