[GRASS-dev] another not quiet GRASS command

[Michael Barton]

On 9/3/07 3:58 AM, "Hamish" <hamish_nospam at yahoo.com> wrote:

>> It does nothing except lock up scripts that don't make special
>> arrangements to parse such stuff.
> 
> Because the calling wrapper is deficient, not the concept of warnings and
> error messages. All scripts must make special arrangements to parse
> such stuff. This can be aided by a wrapper fn, in the same way as the Tcl
> GUI menu has different 'spawn' module launchers. The cure is to fix the
> wrapper -- not hide the errors. It is fundamentally wrong to assume that
> anything written to stderr automatically means a problem is fatal, and
> the GUI code needs to be written with that in mind, even if it is a pain.
> 
>> It would make life so much easier for scripting if we could optionally
>> turn off ALL returned message except stdout for commands that are
>> supposed to return a value and stderr for real errors.
> 
> Warnings and fatal errors are "real errors". I guess one problem lies in
> the concept of the warning. Is it a warning that the user is sailing in
> dangerous waters? or is it a warning that the binary executable module
> did something unexpected, but non-fatal? (I'd argue both are needed). Is
> it a line item to be logged in GIS_ERROR_LOG or a console? or is it a
> standalone pop-up GUI message? (I'd argue that the GUI needs a console).

The GUI has a console. Errors were being routed to the console, but overall
it is a better user experience to have real errors showing up in
GUI-appropriate message boxes than expect a user to search for it in a
terminal or other console. This also doesn't solve all problems of warnings
being mistaken for real errors.

> 
> 
> 
> Note in the C API there is G_suppress_warnings() (in lib/gis/error.c),
> /*!
>  * \fn int G_suppress_warnings (int flag)
>  *
>  * \brief Suppress printing a warning message to stderr
>  * 
>  * \param[in] flag a warning message will be suppressed if non-zero value
> is given
>  * \return previous flag
> */
> 
> Use that at your own peril, it is likely that it will accidentally cause
> more trouble than it solves.

I don't disagree with these concepts. However, the difference is between a
message that is returned when a module operates as designed (regardless of
whether a user might be venturing into dangerous territory or not) or does
not operated as designed. When buried inside a complex script that chains
together multiple commands, something that causes a module to NOT operate as
designed (an error to me at least) can result in unexpected or undesired
behavior or crash the whole script. This needs to be reported 'outside' the
script so that the user can learn what is going wrong 'inside'. But when the
module is working as designed, sending a message is pointless. If it is a
message that triggers an error trap that requires the user to press an OK
button the message itself can bring down the whole script.

> 
> 
> ... so instead of lots of open and catch statements, I'd suggest that any
> call to a module be done using a standard wrapping function, and that
> standard wrapping function take care of robust open/close & error
> handling, once & correctly. I don't think there's another good way.
> Duplicating robust error handling for all external calls is wasted
> duplicated effort and as you point out, a pain.

I definitely agree. This is what has been done with wxgrass. Martin created
a cmd.Command function that will execute a GRASS command using
subprocess.Popen and do a lot of this housekeeping. It doesn't completely
get rid of the need to individually trap potential errors with the try
function, but it helps a lot.

However, this STILL hits the same problem with warnings. Since they come in
through stderr, they apparently produce a non-zero return value for Popen.
This triggers the error management routines--as it should--raising a message
box that says g.mapset failed when it in fact did not.

Michael

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton