conversion of warnings to errors in MATLAB - matlab

In some of my functions I want to convert some warnings into errors. For example, if I want to throw an error when str2func yields a MATLAB:str2func:invalidFunctionName warning, I would do the following:
invalid_func_id = 'MATLAB:str2func:invalidFunctionName';
%hide warning of interest
warning('off', invalid_func_id);
%this might yield the warning of interest
predicate_func_try = str2func(predicate_func);
[~, warn_id] = lastwarn;
assert(~strcmp(warn_id, invalid_func_id)...
, 'MyFunc:InvalidFunctionName'...
, 'The predicate function %s does not have a valid name'...
, predicate_func...
);
warning on all
This works fine if I know that a particular block of code can give a small set of warnings. However it is verbose and probably doesn't scale to larger code blocks. Is there a better way of doing this? Ideally I would want a function which can turn certain warnings to errors in a whole block. It would allow me to modify my example to:
warnings2errors('MATLAB:str2func:invalidFunctionName');
predicate_func_try = str2func(predicate_func);
warnings2errors('off');

Another method would be to overload warning itself. See implementation of warning.m and warning2error.m below. The biggest side effect I see from this is that you will see an extra "warning.m" displayed on the stack for all warning messages. Not sure if there's a way around that. Also, you would need to disable the MATLAB:dispatcher:nameConflict warning since we're overloading a builtin.
EDIT: Just noticed on matlabcentral.com an undocumented use of the builtin warning that accomplishes this:
http://www.mathworks.com/matlabcentral/newsreader/view_thread/158768
http://undocumentedmatlab.com/blog/trapping-warnings-efficiently/
>> warning('error','MATLAB:str2func:invalidFunctionName')
USAGE FROM COMMAND LINE
warning2error('add','MATLAB:str2func:invalidFunctionName')
Warning.m:
% Overload of warning.m to enable conversion of certain warnings to errors
% via warning2error.m
%
% Will want to disable warning "MATLAB:dispatcher:nameConflict" via command
% warning('off','MATLAB:dispatcher:nameConflict');
%
% Jesse Hopkins
% Oct. 2 2012
function varargout = warning(varargin)
%check for component:mnemonic syntax
if nargin >= 2 && ischar(varargin{1}) && any(regexp(varargin{1},'^(\w+:\w+){1,}$','start','once'))
%we've captured <component>[:<component>]:<mnemonic>syntax
%check if this is in the list
if warning2error('query',varargin{1})
%YES, convert to error
ME = MException(varargin{1},varargin{2:end});
ME = ME.addCause(MException('Warning2Error:ConvertedWarning','Converted warning "%s" to error becuase it was registered via warning2error.m.',varargin{1}));
ME.throwAsCaller;
end
end
%pass through to built-in warning
varargout{1:nargout} = builtin('warning',varargin{:});
end
Warning2Error.m:
%warning2error.m
%USAGE:
% Add warnings to convert to errors.
% warning2error('add','<component>[:<component>]:<mnemonic>',...
%
% Remove warnings to convert to errors
% warning2error('remove','<component>[:<component>]:<mnemonic>',...
%
% Query warnings to convert to errors
% tf = warning2error('query','<component>[:<component>]:<mnemonic>')
%
% Get entire list of warnings converted to errors
% list = warning2error('get')
%
% Jesse Hopkins
% Oct 2 2012
function varargout = warning2error(op,varargin)
persistent list;
if isempty(list)
list = {};
end
varargout={};
switch lower(op)
case 'add'
list = unique([list(:);varargin(:)]);
case 'remove'
for i = 1:length(varargin)
[tf idx] = ismember(varargin{i},list);
allidx = 1:length(list);
newidx = setdiff(allidx,idx);
list = list(newidx);
end
case 'clear'
list = {};
case 'get'
varargout{1} = list;
case 'query'
out = false(1,length(varargin));
for i = 1:length(varargin)
out(i) = ismember(varargin{1},list);
end
varargout{1} = out;
end
end

I'm not aware of a clean way to do exactly what you want. Depending on your reason for wanting to turn errors into warnings, you may be able to get by with:
dbstop if warning
or
dbstop if warning MyFunc:InvalidFunctionName
You can also look at warning on stacktrace, to get more infomrat6ion on warnings as they appear.
If you need an actual error message (not just a way to break into the debugger) then I'm actually pretty impressed with the method you included in the question.

It was mentioned as an edit by jHops, but this technique is so simple, it deserves its own concise answer.
As (un)documented in https://undocumentedmatlab.com/articles/trapping-warnings-efficiently, to turn warnings to errors, simply do
s = warning('error', 'MATLAB:nearlySingularMatrix');
where the second string is the warning ID itself. It can be found by warning on verbose in cmdline, and inspecting the warning message. In my experience, it can be further debugged by turning on dbstop if error; dbstop if warning; dbstop if naninf, depending on your issue.
This is a full example for inverting a matrix and checking if it's singular. The last line turns the warning-errors back to regular warnings. s can be either a single warning state as above, or an array.
s = [warning('error', 'MATLAB:nearlySingularMatrix'), warning('error', 'MATLAB:singularMatrix')];
try
Minv = inv(Mat);
InvertFail = false;
catch
InvertFail = true;
return;
end
warning(s);

I found a way to generalise this somewhat. It works the following way (similar to tic and toc):
warn_ids = setwarnings2errors('MATLAB:str2func:invalidFunctionName');
predicate_func_try = str2func(predicate_func);
getwarnings2errors(warn_ids);
Between setwarnings2errors and getwarnings2errors, all warnings set will throw an error if they are the last warning thrown. Therefore it shouldn't be used in large blocks where many different warnings can happen. I implemented the functions the following way:
setwarnings2errors:
function warning_ids = setwarnings2errors(varargin)
warning_ids = cell(nargin, 1);
for x_ = 1:nargin
local_arg = varargin{x_};
assert(ischar(local_arg));
evalin('caller', sprintf('warning off %s', local_arg));
warning_ids{x_} = local_arg;
end
end
getwarnings2errors:
function getwarnings2errors(warning_ids)
[lastwarn_str, lastwarn_id] = evalin('caller', 'lastwarn');
num_warns = numel(warning_ids);
try
for x_ = 1:num_warns
local_warn = warning_ids{x_};
assert(~strcmp(local_warn, lastwarn_id)...
, lastwarn_id...
, lastwarn_str...
);
end
catch m_e
evalin('caller', 'warning on all');
throwAsCaller(m_e);
end
evalin('caller', 'warning on all');
end

Related

'too many output arguments' error when passing function to another function in Matlab

I have some error handling code that I want a bunch of functions to use, so in order to avoid repetition I thought I would put it in my generic class that holds utility functions FunctionContainer.
Here's a truncated version of FunctionContainer:
classdef FunctionContainer
methods (Static)
function run(func, ExpInfo, logdir, newdir, varargin)
try
func(ExpInfo, newdir, varargin)
catch ME
FunctionContainer.errproc(logdir, newdir, ME)
end
end
function errproc(logdir, newLogDir, ME)
errdir = fullfile(logdir, 'error');
movefile(newLogDir, errdir);
pathParts = strsplit(newLogDir, filesep);
logID = pathParts(end);
newLogText = fullfile(errdir, logID, 'error.txt');
fid = fopen(newLogText, 'wt');
fprintf(fid, '%s\n%s\n', ME.identifier, ME.message);
for i = 1:length(ME.stack)
fprintf(fid, '%i\t%s\n', ME.stack(i).line, ...
ME.stack(i).file);
end
fclose(fid);
rethrow(ME);
end
function newdir = prolog(logdir, id, supfiles)
id = join([id, string(clock)], '_');
newdir = fullfile(logdir, id); mkdir(newdir)
stack = dbstack('-completenames');
files = horzcat({stack.file}, supfiles);
for i = 1:numel(files)
copyfile(files{i}, newdir)
end
end
end
end
Here's the context in which I'm using it:
function realign(ExpInfo)
fc = FunctionContainer;
logdir = ExpInfo.logdir;
ws = fullfile(logdir, 'workspace.mat'); save(ws);
newdir = fc.prolog(logdir, 'realign', {ws});
fc.run(runRealign, ExpInfo, logdir, newdir);
function runRealign(ExpInfo, newdir)
% do a bunch of stuff
end
end
The relevant line in my script ks_main.m that calls realign is
realign(FullData)
I get this error:
8 fc.run(runRealign, ExpInfo, logdir, newdir);
Error using realign/runRealign
Too many output arguments.
Error in realign (line 8)
fc.run(runRealign, ExpInfo, logdir, newdir);
Error in ks_main (line 35)
realign(FullData)
I just don't understand this error in this context. None of these functions is returning anything or has any outputs. I could maybe understand if runRealign were getting too many inputs, and I tried defining runRealign like this
function runRealign(ExpInfo, newdir, varargin)
but that made no difference. Maybe this has something to do with passing a function as an argument to another function? What's the right way to do this in Matlab?
You need to put the # symbol in front of your function argument in fc.run. Always do this when passing a function handle as an argument (https://au.mathworks.com/help/matlab/matlab_prog/pass-a-function-to-another-function.html). Line 8 of realing.m should be:
fc.run(#runRealign, ExpInfo, logdir, newdir);
There are a couple of other issues. One is that you are missing an end at the end of FunctionContainer. This is probably just a typo in your question or else you would also have an error related to this.
Another small implementation detail is that you don't need to use logdir as an argument if it is going to be a field in ExpInfo anyway---you can simply access it from ExpInfo inside of FunctionContainer without having to pass it explicitly to run. Passing both ExpInfo and its field logdir to the same function is unclear and stylistically bad practice. (Which reminds me, you should provide a definition of FullData in your question as well. I had to discern that it requires this field.)
However, this is code as is is also going to cause an exception to be thrown on line 6 of FunctionContainer. The definition of runRealign only takes 2 arguments, but when you try to run it in FunctionContainer you expect 3: func(ExpInfo, newdir, varargin). If I change line 6 of FunctionContainer to:
func(ExpInfo, newdir)
it works.
To make this robust and error free you need either to parse the varargin in FunctionContainer so that it intelligently handles a variable number of arguments (https://au.mathworks.com/help/matlab/ref/varargin.html), or else guarantee that the input function handle points to one that has 2 arguments for ever and always.

Using both strings and functions in Matlab UnitTest diagnostics?

Please refer to the documentation for the testCase.verifyEqual method here. The documentation says that only one of the diagnostic features can be used. My requirement is I need two diagnostics at the same time - strings and function handle. The following is simple example of what I'm trying to achieve,
classdef testArrays < matlab.unittest.TestCase
methods (Test)
function testArraysEquality(testCase)
a = 1:10;
b = 1:10;
incrementFunc = #(x)x+1;
failureCount;
for i=1:length(a)
testCase.verifyEqual(a(i),b(i),'AbsTol',10e-3,['Test failed array element# ' num2str(i) ' failure count ' num2str(incrementFunc(failureCount))]);
end
disp([num2str(failureCount) ' out of ' num2str(length(a)) ' test cases failed']);
end
end
end
The problem is Anonymous function don't store values. On the other hand with the 'assignin' feature shown below, the value can be incremented and stored, but cannot be returned for use inside disp(). Is there any work around for this?
incrementFunc1 = #(x) assignin('caller', inputname(1), x+1);
You can include more than one (as well as more than one type) of diagnostic in the MATLAB Unit Test Framework by simply providing a diagnostic array to verifyEqual. You can actually do this explicitly as follows:
import matlab.unittest.diagnostics.StringDiagnostic;
import matlab.unittest.diagnostics.FunctionHandleDiagnostic;
testCase.verifyEqual(a,e, [StringDiagnostic('some string'), FunctionHandleDiagnostic(#() someFunction)]);
However, the Diagnostic.join method is provided to make that easier:
import matlab.unittest.diagnostics.Diagnostic;
testCase.verifyEqual(a,e, Diagnostic.join('some string', #() someFunction));
In order to do the increment call you are probably going to want to add a failed listener to the testCase in order to increment properly. Note that people/plugins can actually add listeners and execute these diagnostics in passing cases in addition to failing cases. As such your diagnostic messages should not assume that every time they are invoked it is in a failure condition. This not only applies to your incrementing code but also to just the message you are providing. I would suggest that instead of saying:
Test failed array element# 3 failure count 2
you should say:
Tested array element# 3 failure count 2
The framework diagnostic will let you know whether it failed or not. Anyway, takeaway, don't rely on invoking the diagnostics to determine failure count. What then? Take a look at the Events section here. You should listen explicitly for verification failed events in order to add that information to your diagnostics.
For the first solution, I am not sure why you need to provide the failure count for every failure. It seems like that would be very verbose. If you don't need that then you can do something like this:
classdef testArrays < matlab.unittest.TestCase
methods (Test)
function testArraysEquality(testCase)
a = 1:10;
b = 1:10;
failureCount = 0;
testCase.addlistener('VerificationFailed', #incrementFailureCount);
function incrementFailureCount(varargin)
% This is a nested function & has the scope and can see/modify
% the failureCount variable. This could also be done with a
% property on the class ans a method that increments it
failureCount = failureCount + 1;
end
for i=1:length(a)
testCase.verifyEqual(a(i),b(i),'AbsTol',10e-3,['Tested array element # ' num2str(i)]);
end
% I suggest using log instead of disp. If you want it to show up most of the time you can
% log it at Terse (1) verbosity. However, if you don't want to see it you can turn it off.
testCase.log(1, sprintf('%d out of %d test cases failed', failureCount, length(a)));
end
end
end
Is that good enough? If you really want to show the failure count in the diagnostics for each failure you can its just a bit more complicated and requires another nested function (or property access).
classdef testArrays < matlab.unittest.TestCase
methods (Test)
function testArraysEquality(testCase)
import matlab.unittest.diagnostics.Diagnostic;
a = 1:10;
b = 1:10;
failureCount = 0;
testCase.addlistener('VerificationFailed', #incrementFailureCount);
function incrementFailureCount(varargin)
failureCount = failureCount + 1;
end
function displayFailureCount
fprintf(1, 'Failure Count: %d', failureCount);
end
for i=1:length(a)
testCase.verifyEqual(a(i),b(i),'AbsTol',10e-3, ...
Diagnostic.join(...
['Tested array element #' num2str(i)], ...
#displayFailureCount));
end
testCase.log(1, sprintf('%d out of %d test cases failed', failureCount, length(a)));
end
end
end
Does that help you accomplish what you are trying to do?

MatLab function, variable output

function [ muln, varargout ] = my_mul( varargin )
%MY_MUL This function is used to multiply numbers.
% My_mul function multiplies array of entered numbers, and outputs single
% solution.
% For example: my_mul(12, 2, 3, 5) gives ans = 360
if nargout >=1
disp('Error, wrong number of output arguments');
varargout{1} = 0;
return
end
if nargin <= 1
disp('Error, small number of input argumnets');
return
else
muln = 1;
for i = 1:nargin
muln = muln*varargin{i};
end
end
end
Hi, everyone, I'm just doing my assignment for uni and have a qiuck question.
How can I make this function to give an error if it is called with more than one output.(It meant to give only one) Thanks!
In your function definition, you have defined your function to allow for an unlimited number of outputs. The keyword varargout is a place-holder for a variable number of outputs.
As you have stated in your question, you only want one possible output which in your case looks to be muln. So if you simply remove varargout from your function definition, MATLAB should automatically throw an error if too many outputs are requested
function muln = my_mul(varargin)
If you ever do need to use varargout but want to place constraints on how many outputs are provided for any given scenario, you can check the number of output arguments that were requested using nargout and then throw an error with the error function.
if nargout > 4
error('my_mul:TooManyOutputs', 'Too many outputs requested');
end
My opinion is that if a return value is expected the function needs to throw. Otherwise the caller (function calling this function) will expect everything to be ok. Note that disp('Error') gives information to the developer, but it does not give the program any indication on what happens. More importantly, the information does not give any indication of where the error occurs. This can force the developer to do heavy debugging just to find the error, which is completely unnecessary.
The use of variable output arguments should only be used in case a different number of output arguments should be expected. An example is some customized plot function
function varargout = myplot(varargin)
filename = '';
idx = find(strcmp(varargin,'filename'));
if (~isempty(idx) && length(varargin)<idx+1 && ~ischar(varargin{idx+1}))
error('filename property must be followed by a directory');
elseif(~isempty(idx))
filename = varargin{idx+1};
varargin([idx,idx+1]) = [];
end
h = plot(varargin{:});
varagout{1} = h;
if (~isempty(idx))
save(filename, h);
end
varagout{2} = filename;
This function works as plot except it saves the figure to file in case a filename is specified. In case the developer needs the handle it will be returned and in case the developer wants the save directory it can be returned as well. None of these arguments are necessary though. The developer may want to use this function as a standard plot function and this means that the user may want to call myplot as myplot(x,y);which does not return a value. Further note that even if 'filename' is not specified, the function can still return 2 outputs. The second output may be an empty array of char, but two outputs for the caller will never cause a crash.
Also, note that no further error handling is required. The only unchecked crashes are in plot and save. How this is handled may be different for different users and this means that it only is reasonable to let the user catch the error and handle it (as he would have done if save or plot would have thrown).
Apart from this you may also want to have a check so that the number of output variables are within the correct range (in this case 0,1 or 2 outputs).

try/catch and error with empty string

I'm working with someone else's code and I am unfamiliar with try/catch so I made a small, similar example. On line 11, if I write error(''), it doesn't seem to catch the error and increase the index j. However, writing error(' ') or error('bad!') does.
So does having an error with an empty string ignore the error, or am I doing something wrong?
% Just a file to understand the Matlab command try/catch
M = 3;
j = 1;
k = [Inf, 5, 4];
while M>0
try
M = M-1
u = k(j)
if (isinf(u)||isnan(u)), error(''), end;
catch
j = j+1
end
end
Yes, error('') and error([]) and error(struct([])) all do not actually display an error message and abort running code. I personally consider the use of the single string argument version of error to be bad practice in any real code. You should use always use both a 'MSGID' and a 'ERRMSG' when writing errors for your functions, e.g.
error('FunctionName:SubFunctionName:ErrorMSGID','Error message to be printed.')
Alternatively, you can use MException objects in conjuction with throw, rethrow, and throwAsCaller, which allow you to reuse error information. More here.
It is odd, but it's in the documentation for error, for the error('msgString') syntax:
All string input arguments must be enclosed in single quotation marks. If msgString is an empty string, the error command has no effect.
Similarly, if using the error(msgStruct) syntax:
If msgStruct is an empty structure, no action is taken and error returns without exiting the function.
if you have a look to the try documentation you can have an example.
Else want you want for your code it :
M = 3;
j = 1;
k = [Inf, 5, 4];
while M>0
try
M = M-1
u = k(j)
if (isinf(u)||isnan(u)), error(''), end;
catch
disp('I catch an error!');
j = j+1
end
end
Because If you never get an error in your code, it will never go in the catch. So by including error('');, it just to say, go execute the statement in the catch.
But you can just modify your code by replacing the error() by the statements into your catch like this :
while M>0
M = M-1
u = k(j)
if (isinf(u)||isnan(u)), j = j+1, end;
end
EDIT
If you take a look in the documentation, you can found this :
% ERROR(MSGSTRUCT) reports the error using fields stored in the scalar
% structure MSGSTRUCT. This structure can contain these fields:
%
% message - Error message string
% identifier - See MESSAGE IDENTIFIERS, below
% stack - Struct similar to the output of the DBSTACK function
%
% If MSGSTRUCT is an empty structure, no action is taken and ERROR
% returns without exiting the program. If you do not specify the
% stack, the ERROR function determines it from the current file and line.
So no action is taken as you can read. And nothing, so catch don't get any informations.
Not sure why you need it, but here is how it works.
error function does not throw an error with empty string or empty vector ([]) as an argument.
If you don't specify argument at all the error function itself generates the error "Not enough arguments". So it will go to catch.
Another way is to specify an empty structure as an argument.
s = struct();
error(s)
In this case, the error will be generated, but the code will not stop and in general flow you will hear no beep. In your case it should go to catch.

How to write a function that does not throw a "wrong number of arguments" error

I am trying to write a minimal function that can be called with a variable number of arguments but that will not throw a wrong number of arguments error if miscalled.
Here is where I start from :
function varargout=fname(varargin)
% FNAME
% Usage: output=fname(input)
% Arguments check
if(nargin~=1 || nargout~=1)
disp('Function fname requires one input argument');
disp('and one output argument');
disp('Try `help fname`');
varargout(1:nargout)={0};
return;
end
input=varargin{1};
output=input;
varargout(1)={output};
end
However this does not work as I would like it to. Is there a way to write a function that :
never throw a "wrong number of arguments" error (so that the rest of the execution can continue)
accepts variable number of input and output arguments and checks them inside the function
(maybe more tricky) if the number of input / output arguments is not correct, does not replace the value of the provided output arguments (so that any misplaced call does not erase the previous value of the output argument)
I am open to any suggestions / other methods.
Thank you for your help.
UPDATE: thanks to #Amro for his answer, I guess what I miss here is either a call by address of reference for Matlab functions or a way to interrupt a function without returning anything and without stopping the rest of the execution.
Here is one way to implement your function:
function varargout = fname(input,varargin)
%# FNAME
%# Usage: output=fname(input)
%%# INPUT
if nargin<1
varargout(1:nargout) = {[]};
warning('Not enough input arguments.'), return
end
if ~isempty(varargin)
warning('Too many input arguments.')
end
%%# YOUR CODE: manipulate input, and compute output
output = input;
%%# OUTPUT
varargout{1} = output;
if nargout>1
warning('Too many output arguments.')
varargout(2:nargout) = {[]};
end
end
Obviously you can customize the warning messages to your liking...
Also, if you want your function to simply print the message instead of issuing warnings, replace all WARNING calls with simple DISP function calls.
Examples of function call:
fname()
fname(1)
fname(1,2)
x = fname()
x = fname(1)
x = fname(1,2)
[x,y] = fname()
[x,y] = fname(1)
[x,y] = fname(1,2)
The above calls execute as expected (showing warning messages when applicable). One caveat though, in the last three calls, if the variable y already existed in the workspace prior to the calls, it would be overwritten by the empty value y=[] in each...
If I understand your question correctly, then the answer is no. If a caller calls a function like this:
[a, b, c] = fname('foo');
then fname is required to return (at least) three outputs. There's no way to tell MATLAB that it should leave b and c alone if fname only returns one output.