[Mapserver-dev] IGNORE_MISSING_DATA - make this dynamic?

[Steve Lime]

Frank et al. I agree with Frank. I tend to think CGI first and then
MapScript, so solutions need to help both camps and Frank's does this.
However, it's not a priority at all so it shouldn't jump ahead of other
bugs for 4.4. I think a CONFIG option makes sense.

Steve

>>> Paul Spencer <pspencer at dmsolutions.ca> 10/20/04 5:49 PM >>>
Sean Gillies wrote:
> On Oct 20, 2004, at 2:26 PM, Frank Warmerdam wrote:
> 
>> Folks,
>>
>> Currently we have a macro called IGNORE_MISSING_DATA that if defined
>> causes MapServer to quietly proceed if some raster files or
shapefiles 
>> are
>> not found that are expected (such as those from a tileindex, or the
main
>> DATA file for a layer).  It would appear, at least on Unix, that this

>> symbol
>> is normally defined meaning that most mapserver binaries are very 
>> forgiving
>> (but not terribly informative) about layers with missing files.
>>
>> I feel that having it as a compile time directive makes it harder for

>> folks
>> who just receive binaries to control this behaviour.  Also, having it
>> turned on by default makes it harder for folks to debug problems in
their
>> maps as they work.
>>
>> I would like to suggest getting rid of the macro, and instead having
a
>> layer or map level directive (via PROCESSING or CONFIG) to control
this
>> dynamically.  Furthermore, I would like the default be to error-out
on
>> missing data, so the user who anticipates this happening sometimes
would
>> have to add the directive to get the more forgiving behaviour.
>>
>> Any thoughts on this?  Is this a feature that should be put off till 
>> after
>> the 4.4 release?  Should I just forget the idea?
>>
>> Best regards,
> 
> 
> Frank,
> 
> I'd be OK with this.  My preference is for MapServer to set an error,
and
> that this error be handled either by the programmer (in the mapscript
case)
> or (in the CGI case) by blocks of code indicated by processing or
config
> directives.
> 
> Sean
> 
> -- 
> Sean Gillies
> sgillies at frii dot com
> http://users.frii.com/sgillies

I'd like to second Sean in this.  In php/mapscript there are a number of

cases when fatal errors are produced that could be handled much more 
reasonably if mapserver just returned error codes and recorded the 
errors internally in its error stack.  The 'terminate with prejudice' 
approach makes it really hard to build applications that behave 
predictably ;)

Cheers,

Paul


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