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

[Federico Miyara]

Samuel,

Thanks for clarifying. I have still a doubt regardihng the hard coding. 
Functions such as cos and abs, which are
primitives, do declare an excess of arguments:

--> cos(6,7)

cos: Wrong number of input argument(s): 1 expected.

Is the behavior different for primitives or they have a way of bypassing 
the hard-coded detection?

Regards,

Federico Miyara


On 06/02/2020 18:35, Samuel Gougeon wrote:
> 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
>
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users

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