More useful msSetError message clobbered by less useful msSetError message

[karl-ms@…]

Let's say I'm generating an SVG file.  msImageCreateSVG gets called, but is unable to get the output 
stream open, like for example, the directory path in IMAGEPATH doesn't exist...

msImageCreateSVG does an msSetError for "Failed to open temporary svg file" and returns NULL.

msDrawMap, detecting a NULL image from msPrepareImage, does an msSetError for "Unable to 
initialize image.", clobbering the "Failed to open temporary svg file", which was actually a lot more 
useful in debugging the problem -- there are many paths by which "Unable to initialize image" can be 
generated.

Suggest mapscript stack errors, generating an error traceback if you will, or do something else, like not 
call msSetError the second time or have msSetError not overwrite a prior undelivered error.  In any case, 
it would be great to get the error back that more closely points to the problem.

[sdlime]

MapServer does stack the errors and MapScript exposes a function called
msGetErrorString to gain access to all of them. For example, in Perl you do
something like:

  $map = new mapscript::mapObj('buffer.map') or die
mapscript::msGetErrorString("\n");

Does that solve the problem?

Steve

[karl-ms@…]

That doesn't help.  In fact, I'm actually doing that.  Here's my equivalent:

::mapscripthelpers::dienull {set ::baseMap [::mapscript::mapObj -filename "flights.map"]}

I was getting the report of "Unable to initialize image", actually, when trying to draw the map:

::mapscripthelpers:;dienull {set mapImage [$map draw]}

I used gdb to trace through the draw (msDrawMap) where I saw the first call to msSetError from 
msImageCreateSvg which said "Failed to open temporary svg file" and then when returning to the caller, 
msDrawMap, msDrawMap has an "if (image == NULL)" piece where, if it is, it calls msSetError again to 
say "Unable to initialize image."

So I don't think there was a way or a place to split the calls and check for an error return... Both errors 
get generated by one call to msDrawMap.

[sdlime]

The reason we went to an error stack was to avoid having to know what errors or 
warnings might be being set further down in the code. Moving away from that 
would be a lot of work (i.e. it won't happen). 

What scripting language are you using? I don't see how the code you've supplied 
is equivalent to calling msGetErrorString unless you're doing it elsewhere on 
failure.

Steve

[szekerest]

I've tested msGetErrorString and it concatenates the multiple messages to one
message string using the given separator. In the earlier versions there was an
issue that it has truncated the message but this behaviour was fixed long time ago.

Tamas Szekeres

[hobu]

Closing. Re-open if this is still a problem. RFC 18 also addresses a number of related msSetError issues...