[Scilab-users] Awkward behavior of error handling

classic Classic list List threaded Threaded
6 messages Options
fmiyara fmiyara
Reply | Threaded
Open this post in threaded view
|

[Scilab-users] Awkward behavior of error handling


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

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, 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.

Regards,

Federico Miyara 


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: Awkward behavior of error handling <= for a too big number of inputs

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
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
fmiyara fmiyara
Reply | Threaded
Open this post in threaded view
|

Re: Awkward behavior of error handling <= for a too big number of inputs


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
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: Awkward behavior of error handling <= for a too big number of inputs

Here is the explanation : when you write a macro prototype, e.g. like this one

function foo(x)

endfunction

when you call it with too many arguments, then the error always triggered by the parser.

When you call the function with not enough arguments, then the variable scope takes precedence. For example the following is legal:

x=1
foo()

i.e. even when not enough input arguments, then the call may be OK, but hopefully argn(2) will have the correct value, i.e. 0 above. That is the reason why the parser always allow the call when there is not enough arguments, leaving the body of the macro do the verification, if necessary.

To me this kind of scoping is always source of error and side effects. Accessing the calling context variable by value is OK, but that formal arguments may be asssigned like this id very prone to errors, at least for beginners.

S.

Le 07/02/2020 à 06:09, Federico Miyara a écrit :

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
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users
-- 
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
fmiyara fmiyara
Reply | Threaded
Open this post in threaded view
|

Re: Awkward behavior of error handling <= for a too big number of inputs


Stéphane,

Thanks for the explanation.

I find it
already dangerous that a function be aware of the calling level variables of equal name. But allowing so even for input arguments is too much. I agree with you.

Generally, variables inside a function are bound or dummy variables. Any other variable or parameter to be collected from the context should be passed through the arguments. This is much safer and better programming style, I think, since everybody is aware of the
previously assigned variables required to be to be able to apply the function. 

I guess a macro designed for general use will never ever exploit this feature...

Regards,

Federico


On 07/02/2020 05:14, Stéphane Mottelet wrote:

Here is the explanation : when you write a macro prototype, e.g. like this one

function foo(x)

endfunction

when you call it with too many arguments, then the error always triggered by the parser.

When you call the function with not enough arguments, then the variable scope takes precedence. For example the following is legal:

x=1
foo()

i.e. even when not enough input arguments, then the call may be OK, but hopefully argn(2) will have the correct value, i.e. 0 above. That is the reason why the parser always allow the call when there is not enough arguments, leaving the body of the macro do the verification, if necessary.

To me this kind of scoping is always source of error and side effects. Accessing the calling context variable by value is OK, but that formal arguments may be asssigned like this id very prone to errors, at least for beginners.

S.

Le 07/02/2020 à 06:09, Federico Miyara a écrit :

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
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users
-- 
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: Awkward behavior of error handling <= for a too big number of inputs

Le 07/02/2020 à 10:30, Federico Miyara a écrit :

Stéphane,

Thanks for the explanation.

I find it
already dangerous that a function be aware of the calling level variables of equal name. But allowing so even for input arguments is too much. I agree with you.

Generally, variables inside a function are bound or dummy variables. Any other variable or parameter to be collected from the context should be passed through the arguments. This is much safer and better programming style, I think, since everybody is aware of the
previously assigned variables required to be to be able to apply the function. 

I guess a macro designed for general use will never ever exploit this feature...


There are always exceptions ;-)
Because, despite its drawbacks, this feature can also be very handy when there is an important needed context.

Noticeably in case of recursivity.

So, things are not all white or black.

When you see an Object-Oriented Programming language, almost nothing is passed through input parameters.
The major useful and used contents are "implicit" and contextual, in classes.

This makes OOP IDEs such Eclipse or others almost mandatory, to easily get explicitly the hidden context of any object (or function). Otherwise, programming would turn just awful.

Samuel



_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users