Clear Filters
Clear Filters

Warning while overwriting a workspace variable?

19 views (last 30 days)
Hello all,
is there a way a notification (warning/error/log) be issue when a base workspace variable is overwritten?
I have number of constants and parameters defined in various .m scripts.
I fear there might be constants with different values in some of the files . So whenever a variable is overwritten, I want to have some alert/logging.
Is this possible?
Basically, if a variable to be added to the workspace already "exists", it (some hook function or so) should somehow notify.
KSSV on 21 Jan 2019
S = who ; % gets all variables in cell
if any(strcmp(S,variable)
disp('variable exists')
disp('No variable exists')
John D'Errico
John D'Errico on 21 Jan 2019
Edited: John D'Errico on 21 Jan 2019
But you still cannot do what you want. Wanting something is rarely sufficient for it to happen in life, even if you want that very badly. You need to do something.
So there is no warning issued when a base workspace variable is changed when you use scripts. This cannot be done in MATLAB, because running a script is something equivalent to just writing commands at the command line in the current workspace. (If you call a script while inside a function, the script operates in the function workspace.)
Have you written code (apparently a script) that the users will run and use? This is generally a really bad idea, by the way. Instead, you should learn to use functions. Or are you running code, where the users will provide input into the base workspace? The same comments apply, as to how bad of an idea that is.
In order for you to protect the base workspace, that means you need to work in a protected environment. That protected environment in MATLAB is a function. So you need to use functions in some way. I can quickly think of two that will work. Maybe a third way.
  1. Force the users to provide a function, one that returns the workspace variables necessary. You will call the function. It will be defined to return those variables of interest, and only those variables. If necessary, you can always add an appropriate function header line yourself to that file before running it.
  2. (Better) Convert YOUR operations into a function.
  3. Write a parser, wherein you programmatically verify each script before it is run. This parser would read each line of the scripts in question, checking to see if any variables of interest would have been changed. Depending on how creatively nasty are your users who supply the scripts, this parser could be very difficult to write.
The alternative is to accept the risk that the users step on your workspace variables. If you don't wish to accept that risk, you need to change your work flow in some way.

Sign in to comment.

Accepted Answer

Steven Lord
Steven Lord on 21 Jan 2019
While you can do this for certain types of variables (create a class and have that class's delete method issue a warning when executed) I'd propose a different solution. Since you mention this is in the context of a Simulink® model, consider using one of the other data storage techniques described on this documentation page. I haven't used these techniques myself, but based on your use case it sounds like a data dictionary may be useful in sharing data between the various models the different people or groups of people have written.

More Answers (1)

Jan on 21 Jan 2019
A method for such warning would cause a tremendous trouble. See this script:
% Script called from base workspace:
a = 0;
for k = 1:10
a = a + 1;
Now each iteration would display a warning, because a is overwritten. What about the automatically created variable "ans", when an output is not caught?
Using sloppy scripts on one hand, but expecting a secure access of the calling workspace is a contradiction. If you care about reliable code and a restricted access to the base workspace, us functions. If you really need to create a set of variables in the base workspace finally (is this really required for calling Simulink?), use function to create a struct at first, and copy the fields of the struct to the workspace at the end:
function Main
S = struct([]);
S = yourFunc1(S);
S = yourFunc2(S);
function S = yourFunc1(S)
S.Param = 7.187;
function S = yourFunc2(S)
S.Value = pi + 2;
function PokeStructToBase(S)
% Evil! This can cause troubles if the field names are bad:
F = fieldnames(S);
for k = 1:numel(F)
assignin('Base', F{k}, S.(F{k})));


Find more on Variables in Help Center and File Exchange

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!