[Scilab-Dev] [warning()] Extending management mode for a specific message

Clément David clement.david at scilab-enterprises.com
Thu Apr 7 10:01:12 CEST 2016


Hello Scilab devs, hello all,

If you track the codereview, you may have notice that I made some warning() modification [1] to
centralize warning message management. The idea is to allow a specific message management instead of
globally shut off the warnings.

Samuel reacted rapidly and I totally agree that it might need to be discussed. Let's copy the first
remarks there and continue the discussion.

> The "stop" flag has been introduced in quite "urging" circumstances, without (public) discussion.
> Yet, it has a meaning completely different 
> than for other flags, since it introduces the fact that we can specify a 
> "do on warning" action. This is a useful feature, but imo it should be 
> extended. It would be much more powerful and used if it was a hook for
> any action (pause, whereami, disp("additional info"), etc).

It might be a major behavior modification but I am also in favor of such a change, especially I was
initially a bit confused about the 'stop' mode that does not map any existing Scilab behavior. The
mode management below might be available either globally or for a specific warning. To ease
implementation, I suggest to have :

 1. "on"      : enable a warning
 2. "off"     : disable it
 3. "error"   : throw an error (previously named "stop")
 4. "pause"   : pause scilab on warning, might be useful to quickly manage them
 5. "execstr" : might execstr an extra argument as Samuel suggested. This might superseed "error" 
                or "pause" but is harder to use as it will require an extra argument.

> In the same idea, some other languages (i have PHP in mind) have a series 
> of warning levels (notices, warning, etc). Managing things in the such a 
> way in Scilab would be nice.

Yep I am fully aware of such a feature in the Java world [2]. With such concepts everything is an
error with an associated level and depending on the display (or logged) level the user might see an
error, a warning or just an information. On that point we might also migrate existing functions to
manage mode arguments similarly to warning().

AFAIK in Scilab, the following functions might behave similarly :

 error()
 warning()
 // may be disp() or print() but the usage might differ

and to manage other (less critical) levels, I only suggest to have logger fonctionnalities in an
external toolbox at this time.


> Finally, -- may be it is mainly about the documentation -- warning() has 
> 1) syntaxes used to trigger already existing actions (standard display, 
>    stop), etc, to write in the code ; and
> 2) syntaxes that control how Scilab must behave when it meets a warning
> These are two clearly distinct sub-sets of instructions. In the help, they
> are not clearly separated, and i get quite confused when reading it.
> It was not so disturbing when only "on" "off" was available. But it is 
> no longer the case.

Yep I tried to separate the two concepts : display and special modes ; but with the introduction to
specific message targets the initial display feature is lost in the mass. I will update the help to
manage that.


[1]: https://codereview.scilab.org/#/c/18041
[2]: https://docs.oracle.com/javase/8/docs/api/java/util/logging/Logger.html

Thanks for your remarks and request on this topic,

--
Clément



More information about the dev mailing list