[GRASS-dev] lib fn to convert int color number to RGB values?

[Ivan Shmakov]

>>>>> Glynn Clements <glynn at gclements.plus.com> 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.

[...]