Prevent mlint warning for onCleanup like return value

I wrote a function, similar to onCleanup. I noticed that Matlab does not give a mlint warning for the following code.

dummy = onCleanup( @() some_func );

But for my own function

dummy = MyOwnCleanup( @() some_func );

I get the warning Value assigned to variable might be unused, which I need to silence with %#ok<NASGU>. Obviously, Matlab recognizes the onCleanup call and does not emit a warning. How can I acchieve similar behaviour for my own MyOwnCleanup function?

[Rik]

This is probably not possible without major interference with the editor. It will probably be an ugly hack.

A much easier hack is to overload the built-in onCleanup function. I don't think I would recommend this.

What exactly is your version doing? I might be interested in using it myself.

[tommsch]

For the original onCleanup function I do not like that it is often a little verbose. E.g. to change the working directory back you have to do

olddir = pwd;

cleandir = onCleanup( @() cd(olddir) );

So I wrote a cleanup function which accepts parameters, so you can write

cleandir = onCleanup_lazy( @(x) cd( x ), pwd );

[tommsch]

What is the worth of that answer. You just repeated my question and all the stuff I know. Are you a ChatGPT bot? You may consider to delete your answer to reduce spam - I will delete my reply then too.

[Umar]

Hi @ tommsch,

You mentioned,” You just repeated my question and *all the stuff I know* “

Now, in your posted comments, you mentioned,

“I wrote a function, similar to onCleanup. I noticed that Matlab does not give a mlint warning for the following code. dummy = onCleanup( @() some_func );”

Could you please click the mathworks mlint documentation link below and tell me what does it say about mlint

https://www.mathworks.com/help/matlab/ref/checkcode.html

Answer 1

[Steven Lord]

So I wrote a cleanup function which accepts parameters, so you can write

cleandir = onCleanup_lazy( @(x) cd( x ), pwd );

Be careful with how you implement this if some of the parameters are state-dependent. What you've written here is fine, as pwd will be evaluated when onCleanup_lazy is called and the value returned by that function is what would be captured. I assume onCleanup_lazy is implemented something like:

function oc = onCleanup_lazy(fh, varargin)
fh2 = @() fh(varargin{:});
oc = onCleanup(fh2);
end

But consider if you'd written your onCleanup_lazy call slightly differently.

cleandir = onCleanup_lazy( @() cd(pwd));

This wouldn't do what you wanted, as pwd would only get called when the onCleanup object returned by onCleanup_lazy was being destroyed. This is likely well after you changed away from the directory that was pwd when you called onCleanup_lazy, and so that onCleanup object would have done nothing.

Getting back to your original question, I believe onCleanup is handled specially by Code Analyzer. Code Analyzer "knows" (aka we told Code Analyzer) that onCleanup objects generally aren't going to be interacted with in code after they were created. [Occasionally, if you want to control exactly when their tasks are executed, you may want to delete them, but that's about it.] Therefore we exempted it from the "This variable may be unused" check. I don't believe there is a way for users to instruct Code Analyzer that it should exempt their objects from this check as well. You could contact Technical Support and request a way to specify in the definition of a function or class that uses/instances of this function or class should not issue this Code Analyzer warning.

[Umar]

Hi @tommsch,

Please see my response to your posted comments below.

Mimicking the behavior of onCleanup

Here’s how to create your own cleanup function (MyOwnCleanup) that mimics the behavior of onCleanup, while also avoiding the mlint warning about potentially unused variables.

First, you need to define the MyOwnCleanup function. This function will store the provided function handle and execute it upon object destruction (similar to onCleanup).

classdef MyOwnCleanup < handle
  properties (Access = private)
      CleanupFunc
  end

    methods
        function obj = MyOwnCleanup(func)
            if nargin > 0 && isa(func, 'function_handle')
                obj.CleanupFunc = func;
            else
                error('Input must be a function handle.');
            end
        end

        function delete(obj)
            if ~isempty(obj.CleanupFunc)
                obj.CleanupFunc();
            end
        end
    end
  end

In this implementation, I created a class MyOwnCleanup which inherits from handle, allowing to utilize MATLAB's object-oriented capabilities for cleanup. The constructor takes a function handle and stores it and the delete method is overridden to call the stored cleanup function when the object is destroyed.Next, use MyOwnCleanup class without triggering the “codecheck” warning by following these steps:

function testMyOwnCleanup()
  % Sample data for demonstration
  sampleData = rand(1, 10);

    % Creating an instance of MyOwnCleanup
    dummy = MyOwnCleanup(@() cleanupFunction(sampleData));

    % Simulating some processing
    disp('Processing data...');

    % Note: You can leave 'dummy' unreferenced here.
  end

function cleanupFunction(data)
  disp('Cleaning up...');
  disp(data);
end

In this example, I created an instance of MyOwnCleanup passing in a reference to a cleanup function (cleanupFunction) which operates on some sample data. The dummy variable will not trigger a warning because I am not using it after its creation in this context. If you want to explicitly suppress warnings for unused variables in other contexts, you can use the comment directive %#ok<NASGU> as mentioned by you in your recent comments. However, with proper object-oriented design as shown above, you may avoid needing this directive altogether. Please see attached.

Explanation of the Output

When you run the testMyOwnCleanup() function, the following sequence should occur: The line sampleData = rand(1, 10); will generate a 1-by-10 array of random numbers which is stored in the variable line dummy = MyOwnCleanup(@() cleanupFunction(sampleData)); creates an instance of the MyOwnCleanup class, passing a function handle that points to cleanupFunction, which takes sampleData as an argument. The message "Processing data..." is displayed, indicating that some processing is happening within the function. When the dummy object goes out of scope (since it is not referenced after its creation), MATLAB's memory management triggers the object's destructor (delete method). This is where the core functionality of MyOwnCleanup is demonstrated. Inside the delete method, since CleanupFunc contains a valid function handle, it executes the cleanup function: The output "Cleaning up..." is displayed. Then, it prints the contents of sampleData showing both columns 1 through 6 and columns 7 through 10 of the random data generated earlier.

Behavior Achieved by MyOwnCleanup

So, this output illustrates how the MyOwnCleanup class successfully encapsulates cleanup logic that executes automatically upon destruction of its instance. Here’s how it achieves this behavior: by defining a cleanup function and associating it with an object, you can make sure that necessary cleanup operations (like releasing resources or displaying important information) are performed without requiring explicit calls to these functions. The constructor checks if the input is a valid function handle and stores it securely for later use. So, you can see that this design allows any function conforming to this signature to be used for cleanup. Overriding the delete method allows for specific actions to be executed when an object is destroyed, to make sure that cleanup operations happen seamlessly and automatically when no longer needed.

mlint warning

Addressing your query regarding, “I wrote a function, similar to onCleanup. I noticed that Matlab does not give a * mlint warning* for the following code.dummy = onCleanup( @() some_func );”

After going through mlint documentation provided in the link below, it states that mlint is not recommended, please see attached.

and suggests using checkcode, for more information please refer to

https://www.mathworks.com/help/matlab/ref/checkcode.html

so I suggest that you should try running your code through this tool if you get a chance. The checkcode function provides a more comprehensive analysis and will help identify potential issues in your custom function.

[tommsch]

Thanks for this long answer, but you still did not adress my question.

1) Part of the confusion may be that, I do not mean the deprecated 'mlint' function, but the warning given directly in the IDE of MATLAB which gives the warning. But note that, 1) the IDE gets its warning messages from mlint - and 2) checkcode internally just calls mlint. So it does not matter whether I talk about mlint or any other tool - They all report the same.

2) In your example I still get a warning in the line marked with "% (*) MLINT WARNING".

function testMyOwnCleanup()
% Sample data for demonstration
sampleData = rand(1, 10);

% Creating an instance of MyOwnCleanup
dummy = MyOwnCleanup(@() cleanupFunction(sampleData));  % (*) MLINT WARNING
% Simulating some processing
disp('Processing data...');
% Note: You can leave 'dummy' unreferenced here.
end
function cleanupFunction(data)
disp('Cleaning up...');
disp(data);
end

3) Apart from that, Note that it is totally unnecessary to inherit from handle here.

[Umar]

Hi @Tommsch,

Please see my response to your comments below.

1) Part of the confusion may be that, I do not mean the deprecatedmlint function, but the warning given directly in the IDE of MATLAB which gives the warning. But note that, 1) the IDE gets its warning messages from mlint - and 2) checkcode internally just calls mlint. So it does not matter whether I talk about mlint or any other tool - They all report the same.

As you correctly pointed out, tools like checkcode utilize mlint under the hood. While these tools are helpful for identifying issues in code, understanding how they interpret code can still help mitigate unnecessary warnings as mentioned in my comments.

2) In your example I still get a warning in the line marked with "% () MLINT WARNING".

function testMyOwnCleanup()
% Sample data for demonstration
sampleData = rand(1, 10);

% Creating an instance of MyOwnCleanup
dummy = MyOwnCleanup(@() cleanupFunction(sampleData));  % (*) 
MLINT WARNING
% Simulating some processing
disp('Processing data...');
% Note: You can leave 'dummy' unreferenced here.
end
function cleanupFunction(data)
disp('Cleaning up...');
disp(data);
end

3) Apart from that, Note that it is totally unnecessary to inherit from handle here.*

Regarding your request to remove inheritance from handle, although in your opinion inheritance is not strictly necessary for this implementation to work, it still allows for better memory management by enabling proper destructor behavior through the overridden delete method. However, I have implemented simpler code snippet without using handle as follows:

   classdef MyOwnCleanup
       properties (Access = private)
           CleanupFunc
       end

       methods
           function obj = MyOwnCleanup(func)
               if nargin > 0 && isa(func, 'function_handle')
                   obj.CleanupFunc = func;
               else
                   error('Input must be a function handle.');
               end
           end

           function cleanup(obj)
               if ~isempty(obj.CleanupFunc)
                   obj.CleanupFunc();
               end
           end
       end
   end

   function testMyOwnCleanup()
       % Sample data for demonstration
       sampleData = rand(1, 10);
       % Creating an instance of MyOwnCleanup
       dummy = MyOwnCleanup(@() cleanupFunction(sampleData));  
       %#ok<NASGU>
       % Simulating some processing
       disp('Processing data...');
       % Call cleanup explicitly (since we are no longer using 
       handle)
       dummy.cleanup();
   end

   function cleanupFunction(data)
       disp('Cleaning up...');
       disp(data);
   end

So, in this revised version of your class (MyOwnCleanup), since you no longer want to use inheritance from handle, you still have to call the cleanup() method explicitly at the end of your processing or when you're done with the object because this change will make sure that cleanup logic is executed without relying on automatic destruction.

[tommsch]

You still did not answer my question. So, lets just close this discussion.

[Umar]

Hi @tommsch,

I do admit not answering your question directly and I am aware of inheriting from handle does allow for automatic resource management which can introduce overhead due to object reference counting. But exchanging ideas back and forth and finding out mlint is not recommended by mathworks documentation will help others when they will try to figure out the same problem as you encountered now in the future. End of discussion.