3:49 p.m.
Hi,
often in user-defined functions we have a bunch of error checks like this:
if maybe_bogus_input
funcerr("cannot do that")
endif
What about adding the if condition to the funcerr() function as a scalar
second argument? So the above would become:
funcerr("can't do that", maybe_bogus_input)
I admit right away that this is mainly one of my syntactic-sugar ideas,
to save 2/3 of the needed lines of code - because in my function
packages and addons the error and input checking block often becomes
quite long.
(However, perhaps there is even a little bit more to it, because one
could pass the extended funcerr() variant to feval() which might open up
new ways.)
Hope everybody's well!
cheers
sven
9:21 p.m.
On Sun, 15 Mar 2020, Sven Schreiber wrote:
Hi,
often in user-defined functions we have a bunch of error checks like this:
if maybe_bogus_input
funcerr("cannot do that")
endif
What about adding the if condition to the funcerr() function as a scalar
second argument? So the above would become:
funcerr("can't do that", maybe_bogus_input)
I admit right away that this is mainly one of my syntactic-sugar ideas,
to save 2/3 of the needed lines of code - because in my function
packages and addons the error and input checking block often becomes
quite long.
(However, perhaps there is even a little bit more to it, because one
could pass the extended funcerr() variant to feval() which might open up
new ways.)
I like the idea here, but my inclination would be to do it via a
function-variant of "catch", as in
catch(maybe_bogus_input, "can't do that")
meaning: if the antecedent is true, do funcerr with the consequent
as error message.
Either way it's an overloading and I'm not sure my suggestion is
better, but to my mind it's more logical to put the condition first,
then the response, and we can't prepend an argument to funcerr
without backward incompatibility. An alternative would be a new
errif() or errorif() function that does the same as catch() above.
Hope everybody's well!
Amen. OK so far here.
Allin
9:32 p.m.
Am 16.03.2020 um 22:21 schrieb Allin Cottrell:
function-variant of "catch", as in
catch(maybe_bogus_input, "can't do that")
meaning: if the antecedent is true, do funcerr with the consequent as
error message.
Either way it's an overloading and I'm not sure my suggestion is better,
but to my mind it's more logical to put the condition first, then the
response, and we can't prepend an argument to funcerr without backward
incompatibility.
That's exactly what I was thinking, too. OTOH funcerr() was introduced
less than 3 months ago (not counting the pre-release phase), so maybe it
wouldn't be too bad to break compatibility here? (After a thorough check
of the packages, of course.)
cheers
sven
12:27 a.m.
On Mon, 16 Mar 2020, Sven Schreiber wrote:
Am 16.03.2020 um 22:21 schrieb Allin Cottrell:
> function-variant of "catch", as in
>
> catch(maybe_bogus_input, "can't do that")
>
> meaning: if the antecedent is true, do funcerr with the consequent as
> error message.
>
> Either way it's an overloading and I'm not sure my suggestion is better,
> but to my mind it's more logical to put the condition first, then the
> response, and we can't prepend an argument to funcerr without backward
> incompatibility.
That's exactly what I was thinking, too. OTOH funcerr() was introduced
less than 3 months ago (not counting the pre-release phase), so maybe it
wouldn't be too bad to break compatibility here? (After a thorough check
of the packages, of course.)
Good point. I'll do a check on the packages and see if it's OK to
make that change.
Allin
8:49 p.m.
On Mon, 16 Mar 2020, Sven Schreiber wrote:
Am 16.03.2020 um 22:21 schrieb Allin Cottrell:
> function-variant of "catch", as in
>
> catch(maybe_bogus_input, "can't do that")
>
> meaning: if the antecedent is true, do funcerr with the consequent as
> error message.
>
> Either way it's an overloading and I'm not sure my suggestion is better,
> but to my mind it's more logical to put the condition first, then the
> response, and we can't prepend an argument to funcerr without backward
> incompatibility.
That's exactly what I was thinking, too. OTOH funcerr() was introduced
less than 3 months ago (not counting the pre-release phase), so maybe it
wouldn't be too bad to break compatibility here? (After a thorough check
of the packages, of course.)
The signature of funcerr() is now revised:
first arg: boolean condition (non-zero means error)
second arg: error message string
Among the current function packages, only Artur's assertion.gfn uses
the prior form (with a single string argument). That form is still
accepted for now; to trigger the new form you must supply two
arguments.
This makes for a nice compact "catch" idiom:
catch <potentially dodgy command>
funcerr($error, "my message")
The funcerr() call won't do anything if $error is 0.
Allin
9:11 a.m.
Am 17.03.2020 um 21:49 schrieb Allin Cottrell:
On Mon, 16 Mar 2020, Sven Schreiber wrote:
>
> That's exactly what I was thinking, too. OTOH funcerr() was introduced
> less than 3 months ago (not counting the pre-release phase), so maybe it
> wouldn't be too bad to break compatibility here? (After a thorough check
> of the packages, of course.)
The signature of funcerr() is now revised:
first arg: boolean condition (non-zero means error)
second arg: error message string
Among the current function packages, only Artur's assertion.gfn uses the
prior form (with a single string argument). That form is still accepted
for now; to trigger the new form you must supply two arguments.
Excellent, thanks! If the single-argument form is supposed to go away
some day, then I'd suggest to make the first argument optional,
defaulting to True. (Not sure right now whether for built-in functions
we can write just a comma to leave that arg out, like we can with
user-defined functions that have defaults.)
thanks
sven
12:50 p.m.
On Wed, 18 Mar 2020, Sven Schreiber wrote:
Am 17.03.2020 um 21:49 schrieb Allin Cottrell:
> On Mon, 16 Mar 2020, Sven Schreiber wrote:
>>
>> That's exactly what I was thinking, too. OTOH funcerr() was introduced
>> less than 3 months ago (not counting the pre-release phase), so maybe it
>> wouldn't be too bad to break compatibility here? (After a thorough check
>> of the packages, of course.)
>
> The signature of funcerr() is now revised:
>
> first arg: boolean condition (non-zero means error)
> second arg: error message string
>
> Among the current function packages, only Artur's assertion.gfn uses the
> prior form (with a single string argument). That form is still accepted
> for now; to trigger the new form you must supply two arguments.
Excellent, thanks! If the single-argument form is supposed to go away
some day, then I'd suggest to make the first argument optional,
defaulting to True. (Not sure right now whether for built-in functions
we can write just a comma to leave that arg out, like we can with
user-defined functions that have defaults.)
Yes, that works, and it's now in git. But I think it's a bit
"irregular" to have an optional leading argument for a built-in
function so I haven't (yet) documented the optionality of the
boolean term.
Allin
1745
days inactive
1748
days old
6 comments
2 participants
participants (2)
-
Allin Cottrell -
Sven Schreiber