[Scilab-users] Awkward behavior of error handling <= for a too big number of inputs

[Samuel Gougeon]

Hello Federico,

Le 06/02/2020 à 22:04, Federico Miyara a écrit :
>
> Dear All,
>
> I'm trying to cast an error message for a function
>
> The test and message are
>
> if argn(2)<>1
>    t1 = "%s: Wrong number of input arguments: %d expected.\n"
>    t2 = "Si"
>    error(msprintf(gettext(t1),t2,1));
> end


Please pay attention to avoid separating the gettext() call from its 
first literal argument. The reason is described with details in the 
gettext() page. So, to abstract, writting both the following is not 
fully equivalent:

t1 = "%s: Wrong number of input arguments: %d expected.\n"
gettext(t1)

and

gettext("%s: Wrong number of input arguments: %d expected.\n")


Here, this separation has no consequence, because you are using a 
standard message that already has a translation in Scilab. But for 
custom messages as in a toolbox, gettext() could here fail finding the 
translation.

>
> The function has only one argument, so if invoked with 0 or more than 
> one argument, the message should be the same. With 0 arguments I get:
>
>
> --> y = Si()
>
>    0.
> at line    26 of function Si ( D:\work_scilab\Si.sci line 26 )
>
> Si: Wrong number of input arguments: 1 expected.
>
>
> This is the correct and expected message. However, with 2 arguments I get
>
>
> --> y = Si(1,2)
>
> Wrong number of input arguments.
>
>
> This error seems to have been trapped before my test, 


Yes, this is the case. This is a general features for all macros. The 
detection of a number of input arguments greater than the max acceptable 
by the macro is hard-coded, and stops the execution BEFORE "really" 
calling and entering the macro. This is the very first step that must be 
passed. Afterward, things actually "occur" in the macro.

> the execution is halted and my message doesn't show. I've also tested 
> the function wavwrite, which requires 2 or 3 arguments. With 0 or 1 
> the message is the expected one, but with 4 or more arguments, I get 
> the same result as in my example.
>
> Seems as if less arguments are handled by the custom error handler, 
> but more than required is handled by sort of a parser.
>
> I think this behavior contradicts the facility of customizing error 
> messages.

Not really. Only this one, related to an excessive number of inputs. 
Since the number of possible distinct errors is infinite, it's cool. Our 
freedom to customize all other messages is also infinite :-))


Regards
Samuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20200206/df471008/attachment.htm>