[Scilab-Dev] Specific errors numbers: true removal becoming a unique flag, or ghosty ones?

Samuel Gougeon sgougeon at free.fr
Sat Apr 14 14:56:34 CEST 2018


Allo?

Le 01/02/2018 à 16:12, Samuel Gougeon a écrit :
> Dear ESI-Scilab devs,
>
> Errors numbers are announced as removed in Scilab 6. Yet, some related 
> features are still active, for instance:
>
> --> error(123)
> error: Wrong type for input argument #1: string expected.    // OK
>
> --> error(123, "message")    // Is this syntax intended to be kept?
> message
>
> --> [t, n] = lasterror()
>  n  =
>    123.
>
>  t  =
>  message
>
> --> execstr("error(456, ""message"")", "errcatch")
>  ans  =
>    456.
>
>
> It looks a bit hard to remove the 2nd lasterror() output, because this 
> would shift last ones (max 4 argouts), and so trigger 
> back-compatibility issues for nothing.
>
> But for lasterror() as for execstr(), the question is, noticeably to 
> be able to update the documentation in a relevant and reliable way:  
> Are specific errors numbers planned to still be possible --then, what 
> for? --, or will a unique 10000 error number be used as a filling 
> output for lasterror() and as a simple output flag for execstr()?
>
> There is also the case of the 999 error number heavily used in the 
> hard code. If 2 distinct error numbers are kept as "standard" flags, i 
> guess that the distinct meaning of each of them shall be explained..
>
> Looking forward to reading you

What i understand:

  * Contrarily to what has been announced: error numbers are not removed
    6.0 CHANGES:
    Feature changes and additions
      o |error|: an error number in the input is deprecated.
    => This is wrong
  *
    In Scilab 6:
      o
        There is no longer any dedicated specific error numbers for some
        frequent error messages: numbers and messages are now
        independent. They are just 2 ways to tag an error.
      o
        As a consequence: error() can no longer be called only with a
        number. Indeed, an explicit message must now be provided, since
        now no message is ascribed to a number

Is this right? Can we go with this description, or do you really want to 
deprecate numbers and actually remove them in 6.1 or later?

Thanks

Samuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20180414/e8536126/attachment.htm>


More information about the dev mailing list