On Sat, 16 Jan 2021, Sven Schreiber wrote:
Am 16.01.2021 um 13:21 schrieb Artur Tarassow:
> Am 16.01.21 um 01:41 schrieb Allin Cottrell:
>> Meybe, but it's operating per documentation: requiring a number of
>> strings equal to the number of columns and returning non-zero on error.
> as it returns an error value, I don't think an error should be thrown
> (which would lead to a full stop I guess - if not catched). The user is
> responsible for testing the returned value in this case.
Right, I overlooked the fact that an error code is provided by the
Actually I'm a bit uneasy about that, even though it's documented.
It's common in libgretl C code, and in many library APIs, to return
0 on success or a non-zero code on failure. It's then up to the
caller to check the return value and decide what to do in case of
error (which might or might not be to abort execution). But it's not
common in scripting languages, including hansl. Generally, one
expects that if a command or function fails, execution of the script
will halt, unless one takes special measures ("catch" in hansl).
Different paradigms, but we're mixing them up, to a degree.
So I would be in favour (not right now, just before release, of
course) of revising the relatively few gretl functions that do the
"return an error code" thing: let them actually fail on error, like
the great majority of functions.
What about the other issue with the right number of --but partly
strings? Checking errmsg(err) shows an 'invalid argument' error. My
workaround is now to insert a one-blank string " " instead of an empty
string "" in those places. I think, however, that it's a valid aim to
only label a subset of the rows or columns, isn't it?
Not sure about that; we can debate it.