In my recent post on MExceptions, a user asked if a syntax error inside a function being called in a try/catch would get caught in older versions of MATLAB. I've done a tiny bit of investigation on this and report it here.
Contents
Syntax Error is Caught
In this first example, I have an outright syntax error in my code.
dbtype err11 function err1( 2 3 a = 3 4 b = 2
You can see that MATLAB can tolerate this, and indeed, seems to tolerate these sorts of errors in a try/catch context at least as far back as MATLAB version 5.3 (Release 11).
try err1 catch disp 'Landed in catch' end
Landed in catch
Unsupported Syntax
Similarly, for syntax that is not possible in MATLAB R2007b (the version used here), again the code jumps to the catch block. In the following code, you see that I try to index into the result of a function without assigning the function output itself to a variable. This is not something supported in MATLAB R2007b (and I have no statement to make about the future of this proposed construct except to say that it is an enhancement in our database and will be considered for the future).
dbtype notPossibleR2007b1 function notPossibleR2007b() 2 3 a = eig(rand(3))(2)
try notPossibleR2007b; catch disp 'Got caught' end
Got caught
Why?
Why might you wish to do this? One reason is if you are accepting user input or code for your application. If the code presented to you has something in it that won't work, you might still like to control the presentation of the error to your user. try/catch with the offending code in a separate file allows you to intercede and do just that.
Another reason to structure code this way is to allow you to take advantage of a new feature if it's available to your user. If not, do things the older, perhaps harder or more time- or memory-consuming way.
Thoughts?
Do you need to "support" multiple versions of MATLAB? Will separating your code this way help? Let me know here.
Get
the MATLAB code
Published with MATLAB® 7.5
Yes, Loren, this is just what I need - Thanks. I try to write code that back-ports to older versions and attempts to be robust against possible future changes (putting try/catch around the use of deprecated functions, so the code works when the functions really get deleted in a future release, for example).
As an aside: I like the suggested enhancement for subsref … assuming it doesn’t cause any chaos. I’m sure MATLAB-golfers will like it too.
Sometimes ideas that look great on the surface get really nasty when you dig into the details, though … like the new bsxfun function (which works well) in contrast to extending the basic syntax to do the same thing (which doesn’t work well at all but is very tempting to consider).
Incidentally, why isn’t
eig(rand(3))(2)
supported? I find myself composing vector- or matrix-valued functions a lot (maybe because I’m a Lisp hacker instead of an old-school Fortran card-puncher ;-) ), and I find it awkward to create temp variables all the time. Of course the notation can get hard to understand after composing a lot of functions, but two or three isn’t too bad for someone who reads a lot of Lisp.
I’m happy to find your blog so now I have someone to pester about Matlab syntax ;-) I’m very grateful, though, that the bugs in the Matlab 6.? parser have been fixed. (There were certain matrix and function call expressions like
[foo (x), 1, 2]
in which the space between the function name “foo” and its argument list broke the parser. Leaving a space between a function name and its argument list is a common habit among C coders who use GNU C formatting conventions. Matlab 7 seems to have fixed this parser bug.)
Many thanks!
Mark-
Lots more good ideas than time is the reason why. It’s certainly been requested and on the enhancement list for consideration.
–Loren
Ha, yes, “more good ideas than time” should be considered a good thing, as it means our work is not yet done! ;-)
mfh