>>>>> Glynn Clements <[EMAIL PROTECTED]> writes:
[...]
>> As lib fns, the one G_fatal_error() would need to change to
>> G_warning(). Or is it better to be silent and rely on the module
>> programmer to check the fn's return code?
> If it's conceivable that the module will continue in the event of an
> error, the function should just return a status code.
> If it's likely that the module is just going to call G_fatal_error()
> anyhow, the library function may as well call it itself, thereby
> providing a "infallible" interface (i.e. the function never fails; it
> either succeeds, or the process is no longer running so the failure
> is moot).
[...]
> The former is only an advantage if there's a situation where a module
> doesn't just call G_fatal_error() when an invalid colour
> occurs. Given that invalid user input is usually a fatal error, I
> can't immediately think of a situation where you might get an invalid
> colour string without it resulting in a fatal error.
Did you consider the use of the function from within a GUI
application? Hardly calling exit () on incorrect input from the
user is a friendly behaviour for a GUI application.
Actually, I see calling G_fatal_error () from a library function
to imply such a marginal improvement on the caller's side, so
I'd not bother with this issue at all and rather never call a
function implying exit () from the library code (with the
exception for the functions clearly intended to call exit (),
or, may be, for the out-of-memory conditions.)
As an additional benefit, it allows the libraries to be used
from high-level languages (like Python or Scheme.) Calling exit
() behind the back of the language implementation (or the
interface author) doesn't sound very friendly, too.
[...]
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
