At The MathWorks, we continue to explore ways to ease your programming learning curve and help you write better code. As such, we have been discussing how stringent to make the messages in mlint with respect to catching errors. Currently, MATLAB doesn't make any particular recommendation about checking to be sure you know which error you got before moving forward. Is that a really good idea? We aren't sure and thought find out your thoughts on this.
Contents
An Example
Let me show you two snippets of code trying to accomplish basically the same task. I will discuss pros and cons of each. Note, I will be using the new MException syntax for try and catch though you can do similar things using the older lasterror mechanism as well.
Snippet #1
try
doSomething;
doMore;
catch myException
cleanUpHere;
maybeThrowOwnNewException;
endSnippet #2
try
doSomething;
doMore;
catch myException
expectedExceptionID = 'MATLAB:dimagree';
if strcmp(myException.identifier,expectedExceptionID)
cleanUpHereAndMaybeThrowError;
else
doDifferentCleanUp;
throwUnexpectedException;
end
endPros and Cons
- snippet #1 is shorter than snippet #2
- snippet #1 never checks that the caught error is the expected one
- snippet #2 does two different operations, depending on whether the error was expected or not
- when snippet #1 does throw its own new exception, since it didn't look at the actual one, the cause may not be correct or meaningful to the user
There's No catch
Another related question arises if the try is not paired with a catch.
What Do You Think M-Lint Should Do?
For the first example, neither code snippet is outright "wrong." Moreover, there are cases, no doubt, where no matter what the actual error is, you have no choice but to do a particular set of operations. However, that clearly isn't always so. So, how forceful would you like to see M-Lint be for the case of snippet #1? Would getting a message there (though not a red one) be helpful?
What about the situation in which there is no catch accompanying the try? Again, there may be a few cases where this makes sense, but typically that won't be so.
Let us know your thoughts about these questions here.
Get
the MATLAB code
Published with MATLAB® 7.5
These questions get into just how intrusive mlint should be. How aggressive/suggestive should it get when it sees something that might not be quite kosher?
Certainly mlint should tell us when there are syntax errors. I also like to see it tell me about missing semi-colons, etc. Simple, obvious mistakes are nice to see. We have even discussed the idea that mlint might ask if you really want to use inv, i.e., do you know what you are doing here.
Mlint started out as a simple code checker. The question is, as mlint grows up, do we want it to become a code advisor? A mentor? A coding big brother? Will mlint one day be intelligent enough that it can write our code for us? Just pass it a handwritten flow chart, and it writes the code?
To what extent should it be providing advice on our coding styles? Will the day come when mlint will decide that “You have shown inadequate proficiency in Matlab coding to use these features. You must now review sections 23-27 of the tutorial before proceeding further.” At this point, Matlab shuts down until the tutorial has been viewed, and perhaps a test is passed by the user.
Ok, this last was said in jest, but at what point does a checker become too intrusive? Should mlint be guiding the user into “approved” styles of coding? How much thinking for the user should mlint do?
John
Personally I am a believer that there is value to being able to use try without a catch. A simple example is when I want to find any file whose contents match some criteria. I don’t really care when it fails, I just want it to move on and try the next one.
As for mlint, one thing I would like to see it do, is to have an option for serious code optimization. So then when you really need to squeeze every operation, it can suggest approaches which have an impact at the very underlying roots of MatLab (for example, “This method requires the allocation of an intermediate variable. It is faster to use…”). Admittedly this may actually be counter to the normal goal of mlint (more maintainable code), but sometimes what I need is pure speed, not clarity of the program.
Dan
John and Dan,
Thanks for the comments so far.
Do you know you can turn messages off from the preferences panel or right-clicking on the message and choosing to have that topic not reported on? That way, even if mlint does have more “style” messages, you can still regulate your interaction with them.
As for performance, if we can identify some code patterns that would be more optimally done another way, we can add those to mlint. But it needs to be a pattern (even if complex). Any candidates?
–Loren
How about replacing repmat with bsxfun? That’s a pretty trivial one.
Dan
The repmat/bsxfun one is an excellent idea. Virtually anywhere you see a repmat, bsxfun probably could be applied with better results.
How about a check for an H1 line?
I did know about being able to turn off the warnings, but I’d never known I could do it via a right click. Neat.
John
One downside to making m-lint more stringent is that it is overly critical of older code, particularly for code that is written to port to older versions of MATLAB. For example, I find that I often have to include %#ok statements whenever I use “if (a | b)”, since m-lint complains that I should use “||”. Well, “||” doesn’t exist in older MATLAB versions, so I must use it. Keeping M-lint quiet is important, since it otherwise wants to say my code is cruddy when posted to the File Exchange.
As an example, see Nick Higham’s Matrix Computation Toolbox, or Cleve Moler’s NCM toolbox. Both are excellent codes, but get dinged in the File Metrics by an overly-aggressive M-lint. They were written before “||” and “&&” were added to the language. Nick’s code also uses the old-style warnings, but M-lint complains there, too.
So, M-lint is made more stringent, then I would recommend not making these settings the default … or at least exclude them from File Metrics posted on the File Exchange.
Great topic…
What about a macro-type setting in the preference for how “aggressive” mlint should behave. A slider from “silent” to “teaching mode” and a few in between could satisfy how we each want to use code checking at different times. Each strictness level could have presets for the individual checks and messages being on or off.
Best,
Rob
This is somewhat related to problem of the MS Word grammer check. People edit their text untill the grammer check is satisfied, but until the text is a good one. I am personally a fan of extremely stringent code, but there is a limit. One example I see is when using GUIDE. M-lint complains about the unused variable which comes with every function and finally I have so many %#ok in my code that I have practically disabled M-lint.
–DA
Daniel-
Part of the issue with GUIDE is that it isn’t generating “up-to-date” code. We know about that and have plans to fix the generated code so it doesn’t trigger M-Lint messages (though that’s NOT the reason for the rewrite — the reason is that we can generate what we think IS better code). Not sure what release this will show up in….
–Loren
What about the unspoken “snippet #0″ which is the way most MATLAB code is written:
doSomething ;
doMore ;
…in other words, code that is not embedded in any try/catch at all. I can’t imagine M-lint complaining here, as in “Warning: you have written code that uses the default MATLAB error/warning handler; this is a Really Bad Thing to do.”
I think that attempts to let M-lint distinguish between snippet #1 and #2 will probably devolve into trying to distinguish between #1 and #0, which will not be helpful.
A better approach at the try/catch error handing would be to allow catch to catch only specified errors. I have often written try/catch code, expecting one error, but had the catch find an error I didn’t want to be caught. I would rather just tell MATLAB to catch just the errors I want to catch, and let the default error handling process catch everything else. It would be a lot simpler to code that way.
For example, if I’m running an experiment on lots of sparse test matrices, I want to catch the out-of-memory condition, skip that matrix, and keep going with other test matrices. What I would really like to specify is something like this:
for k = 1:nmat
try
get the kth matrix
run an experiment on the kth matrix
catch ‘MATLAB:nomem’
oops, out of memory. Just keep going.
end
end
Then if I encounter an unexpected error, MATLAB will properly terminate my code. To do this with the current try/catch, I must use “catch ME” (sounds like a line from the movie “Enchanted”) and then check ME to see if it’s what I expected and then explicitly throw an error if it isn’t Hmm, did I expect ME or someone else ;-) ?. That’s tedious, and tweaking M-lint won’t be of much help, I think.
Tim-
We have registered the request to catch specific errors. I too think that would be a very nice feature, and, as you point out, help write concise code.
–Loren
In my opinion, marking obvious errors or code patterns that can be optimized to speed up code is very useful. However, a “teaching mode” or anything given advice on how to write code is pretty useless.
From my own experience, when I was a beginner, I never understood these kind of messages or warnings and just ignored them. Later, when I learned more about programming and would be able to actually understand the messages, they usually didn’t show up because I wrote better code or if they showed up, in 95% of the cases they annoyed me because I knew what I was doing.
Maybe I’m the exception to the rule, but an easy way to configure mlint would definitely be very helpful. 100 checkboxes where the user can check or uncheck every single message is not the way to go, though!