Finally Clause in Try-Catch

Just making sure

MATLAB Try/Catch does not have the "finally" block? Correct?

I am simulating the behavior using something like this:

% Opening resources
try   
    % Doing stuff with the resources

      % This is at the end of the try block so if the code reaches here
      % this means that everything went well with no problem.
      throw(MException('TryCatchFinally:noWorries', ...
                       ['This exception can be ignored.' ...
                        'This is to just flag that the try block finished' ...
                        'without any error and can be used to simulate ' ...
                        'finally behavior'], ...
                       0));
  catch ME
      % Closing all the opened resources

      % rethrowing error if it is anything other than 'TryCatchFinally:noWorries'
      if (~strcmp(ME.identifier,'TryCatchFinally:noWorries') )
          rethrow(ME);
      end
  end

However raising an exception could affect performance in cases where your code is called several times. The alternative to above code is the following but this second one requires to have the code that closes the resources twice (it's OK though if all I need to do is fclose(fid)):

% Opening resources
try   
    % Doing stuff with the resources

catch ME
    % Closing all the opened resources; 
    % This is called only if any exception is raised in the try block.      
    rethrow(ME);
end
% Closing all the opened resources.

What other method do you guys suggest?

[deepak panday]

isError=true

try

..

...

isError = false

throw(Me)

catch

%% this portion is executed even if error is not in the code segment

if isError

.%% write code here that need to go in error handling

end

%% write code here that need to go in finally portion

end

Answer 1

[Walter Roberson]

ME = [];
try
   %do some stuff
catch ME
end
%close the open resources
if ~isempty(ME)
   rethrow(ME);
end

[Mohammad Abouali]

I like this one. Thanks

Answer 2

[Guillaume]

Yes, there's no finally in matlab.

It remains to be seen if raising exceptions have an impact or not on execution speed. It's not something I've tested.

It certainly seems a bit subversive to use exceptions to trigger normal completion. Probably a better way is to use onCleanup which is even more bulletproof than a finally (if the try ... finally is the whole scope of the function) since it gets triggered even on an abort (CTRL+C):

function myfunc
   %Opening resources
   fid = fopen('somefile');
   cleanfid = onCleanup(@() fclose(fid));  %called on completion of function, whether normally, by exception or abort
   %do stuff with resource
end

[Mohammad Abouali]

I agree. I don't like raising that exception either. Using onCleanup is also good idea. Actually this is a nicer solution. But sorry I already accepted the other answer.

[Jan Siegmund]

Make sure to define the onCleanup object at the Beginning of the function. Otherwise it won't be triggered:

function myfunc
   cleanfid = onCleanup(@() fclose(fid));  %called on completion of function, whether normally, by exception or abort
   %Opening resources
   fid = fopen('somefile');
   %do stuff with resource
end

Because onCleanup is just an Object with a deconstructor executing the function handle.

And the deconstructor is called at the "end" keyword.

And also be aware of other anonymus functions when using onCleanup.

[Steven Lord]

Jan Siegmund: as you've written it the variable fid won't exist at the time you create the anonymous function that you pass to onCleanup. Because of this when the onCleanup function is destroyed and executes that anonymous function it will issue a warning that the anonymous function would have thrown an error. It also doesn't close the file. You can see this by replacing 'somefile' with a file that already exists, calling fopen with the 'all' option (to list all open file IDs), running myfunc, and calling fopen with 'all' again. Put the following code in a file named example300062 and run it.

before = fopen('all')
myfunc
after = fopen('all')
filename = fopen(after);

function myfunc
   cleanfid = onCleanup(@() fclose(fid));  %called on completion of function, whether normally, by exception or abort
   %Opening resources
   fid = fopen('bench.dat', 'rt');
   %do stuff with resource
end

There are scenarios where you can create the onCleanup object before making the change it's intended to clean up. Warning suppression and restoration is one such scenario.

id = 'MATLAB:dummyWarningID';
warnState = warning('query', id);
restoreThatWarning = onCleanup(@() warning(warnState));
warning('off', id)

Even if for whatever reason the warning('off', id) call throws an error that terminates the function in which those four lines of code were executed the state of that warning will be restored by the restoreThatWarning onCleanup object.

But in the file identifier scenario, the onCleanup object needs information returned from the code that makes the change, so it can't be created ahead of time (at least not without being a much bigger hammer, like calling fclose('all').)

[Jan Siegmund]

ah, got it. but the above mentioned post by guillaume wont trigger on ctrl+c, right?

So the right approach would be

function myfunc
   %Opening resources
   fid = fopen('bench.dat', 'rt');
   cleanfid = onCleanup(@() fclose(fid));  %called on completion of function, whether normally, by exception or abort
   %do stuff with resource
end

, wouldn't it?

Where it would catch on issues and ctrl+c at the

%do stuff with resource

part.

[Steven Lord]

If you pressed Ctrl-C while you were doing stuff with the resource in Guillaume's example, the myfunc function would exit. As long as you don't return the onCleanup object from myfunc, it will be destroyed (and the cleanup function executed) as the myfunc function exits.

Ideally you should prefer creating the onCleanup object before making the change you want to clean up (if possible, which it is in the warning suppression case and is not in the file closing case) or as soon afterwards as you can. Anything you ran between the fopen call and the onCleanup call, if it failed, would leave the bench.dat file open.

About the only way you may be able to get a function to terminate without triggering the onCleanup objects in its workspace is to forcibly kill MATLAB (including having MATLAB crash.) If MATLAB Goes Away the operating system should handle reclaiming memory, but it's not going to allow MATLAB to try executing the onCleanup object's destructor.