What is the "penalty" for using a try/catch?

What is the "penalty" for using a try/Catch? E.g.,:

try
  f.start()
catch ex
  %Do something
end

Compared to, lets say:

ok_flag=f.start();
if (ok_flag==false)
%do something
end

Im familiar with the benefits of try/catch, but still wondering about the overhead... Furtermore, what if the "start" function of object f is declared like this:

function start(OBJ)
t=timer;
t.TimerFcn=@...
OBJ.t=t;
start(OBJ.t)
end

Will the overhead remain throughout the lifetime of the timer t?

All the best, Daniel Petrini, Stardots

[José-Luis]

Is this really a bottleneck in your code?

[Daniel Petrini]

Not sure (how can you check?); but i´d like to know what "ballpark" we are in... :-). In addition, what if f.start() calls g.init() that calls h.prepere() etc. and they are all "guarded" by try/catch. Stroustroup warns that try/catch should not be used carelessly.

[José-Luis]

Well, my advise would be not to worry about this. Unless you are in a really performance critical bit of code where every cycle counts (and, imo, you shouldn't be using Matlab if that's the case), this is a moot point.

To answer your question a bit better, what try/catch actually does is actually up to how the Mathworks implemented it. In C++ it would depend on what compiler/platform you are using. There might be overheads because of the extra checks, but those might be negligible in most cases.

[Guillaume]

"Stroustroup warns ...." Matlab is nothing like C++, one is compiled the other is interpreted (with JIT optimisations), the memory management is totatally different, etc.

I agree with José-Luis, you should not worry about performance yet. I'd worry more about code clarity and resilience first, and only when you've shown try...catch to be a performance bottleneck in your application should you think about replacing it.

Note that if you have access to the prerealease of R2017a, you should read its release note, it has something relevant to your question. I'm not allowed to share what it says.

[Daniel Petrini]

Yes, I know the difference between C++ and Matlab; only commenting on the overhead associated with try/Catch that (I guess) exists in every language...

Answer 1

[Guillaume]

The "penalty" has mostly been answered in the comments to the question. I'm posting this as an answer as I think you may have misunderstood how try... catch works, given your example and your question "Will the overhead remain throughout the lifetime of the timer t?"

No, the overheard will not remain throughout the lifetime of the timer t, because the try...catch stops being in effect as soon as the timer starts. (well, when the f.start() function returns, which is pretty much the same). The only thing in your code that can trigger the catch is if the timer fails to start (not sure if it's possible, mathworks does not document this sort of things, unfortunately).

In particular, any error in the TimerFcn will not be caught by you try...catch, because the execution of that function is not in the scope of the try...catch (asynchronous execution). If you want to deal with errors that occur while the timer is running you need to implement a callback for t.ErrFcn.

[Daniel Petrini]

Thank you all for you time and comments. Yes I do realize that try/Catch is not that performance heavy, but a "heavy" utilization of try/Catch in a large application could potentially degrade the (a) user experience and/or application capabilities. In a larger application with many try/Catch it is not so easy to simple flip them off... Also, the profiler seems to sum up the try in one line of code?!. Anywhoo... I will continue to use them :-) /Daniel