Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

MException fallback for Matlab 6.5

Asked by Jan Simon on 14 Jan 2012

The new MException object for try catch expressions is very nice. Unfortunately I still have to support Matlab 6.5. Does anybody use a workaround, such that catch ME is still valid in the historic Matlab versions?

0 Comments

Jan Simon

Products

No products are associated with this question.

2 Answers

Answer by Walter Roberson on 14 Jan 2012
Accepted answer

If you have a mechanism for defining a function or not depending on the version, then you could try:

...
catch ME
  ME_TOO = ME;   %the copy is important
  ...
  disp(ME_TOO.message);  %for example
end
%only build this in if MException is not supported
function Exception = ME
  persistent LastException
  if nargout == 0
    LastException = lasterror();
    LastException.cause = {};
  end
  Exception = LastException;

So when ME appears on the 'catch' statement then the function recognizes it was called with no outputs and records the lasterror. When the function appears in the assignment, it sees the output exists and copies out the remembered exception.

Copying a normal MException object is not a problem. Copying with this replacement gives you a struct whose fields can be accessed (whereas you cannot directly access the fields of a structure returned by a function.)

5 Comments

Jan Simon on 15 Jan 2012

When I understand it correctly, a timer callback can invalidate the persistently stored object, if it it called between "catch ME" and "ME_too = ME". Some time measurements let me assume, that timer callbacks get a chance to execute *after* each line, so perhaps it is more stable to move the function call and the copy to a single line:
catch ME, ME_TOO = ME;

Walter Roberson on 15 Jan 2012

Yes, that is a good point.

Jan Simon on 15 Jan 2012

I've asked the support for a suggestion.
See: http://www.mathworks.com/matlabcentral/answers/21537-what-thread-do-timers-operate-in
and http://www.mathworks.com/matlabcentral/answers/22180-timers-and-thread-safety

Walter Roberson
Answer by Jan Simon on 28 Jan 2012

According to an exhaustive answer from the technical support:

The following code does have a racing condition:

try
  command;
catch ME_, ME = ME_;  % RACING CONDITION in Matab 6.5
  disp(ME.message);
end
% For Matlab < 7.4 only include this in the PATH:
function ME = ME_;
persistent LastException
if nargout == 0
  LastException = lasterror();
  LastException.cause = {};
end
Exception = LastException;

The following applies to Matlab < 7.4 only:

In the line "catch ME_, ME = ME_;" the pressing of Ctrl-C is checked after the semicolon only (according to my investigations), but timer callbacks can be started at the comma also. If the timer-callback catchs an error using the ME_ also, thet persistent variable is overwritten. A possible solution would be using a LIFO stack for the persistently stored exception object. The better solution is to upgrade from Matlab 6.5 - but this might have further consequences.

While under modern Matlab versions the bove code is safe, the workaround for Matlab 6.5 contains a very unlikely chance to get a wrong error message due to the racing condition.

7 Comments

Daniel on 29 Jan 2012

@Jan, can you confirm that the timers in 6.5 are asynchronus

Jan Simon on 30 Jan 2012

@Daniel: No, I will not try to speculate. But I observe this:
I start a timer, which displays the current time every second in the fixedRate mode. Then I run this function:
function test
for i = 1:20
for k = 1:1e7
d = sin(k);
end
% Callback runs here
fprintf('%d\n', i);
end
Then the callback is executed in the marked position only in Matlab 6.5. Without FPRINTF the timer callback does not run inside the function test().

Daniel on 30 Jan 2012

@Jan, Thank you for that. I keep learning new things about how badly behaved timer objects are.

Jan Simon

Contact us