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