1     function y = expMuSig(x,mu,sigma)
2     %Exponential function with parameters mu and sigma.
3     try
4         y = exp(-0.5 * ((x - mu)./sigma).^2) ./ (sqrt(2*pi) .* sigma);
5     catch theRealError
6        theErrorWhichIsALie = MException('LSBlog:sizeMismatch','Non-scalar arguments must follow MATLAB dimension matching rules.');
7        theErrorWhichIsALie = addCause(theErrorWhichIsALie, theRealError);
8        throw(theErrorWhichIsALie);
9   end

Again, what information does “using exceptions and adding a cause” add to the error report that was not already present (i.e. that the program failed while calling expMuSig)?

It is writing “error handling” code in a cargo-cult manner because you *think* you should be writing error handling code everywhere. But the code is carefully constructed to be idempotent to not writing any error handling code at all, other than it additionally gives back some false information that you have to dig down to the “cause” to reveal. What you’ve managed to prove conclusively is that this is a case where you should actually not write “error handling” code, if that code does not actually handle errors.

This post was written before MATLAB had exceptions. I agree that now it would be better written using exceptions and adding a cause.

–Loren

The code segment is idempotent to actually not doing any error checking at all, except it provides even less information to the programmer when it fails. Given the choice between no error checking at all, and that unnecessary catch block the replaces a stack trace with a likely incorrect error message, I prefer no checking.

The purpose of exceptions is to provide useful information to the programmer via an error message and stack trace, and to give code an opportunity to clean up from failures. If you’re not willing to further either purpose, don’t catch exceptions.

I am not sure I understand your question about error checking in MATLAB functions, but I think you are asking if we are always careful about the state of lasterror. I can’t answer definitively, but my guess is that we’re mostly but not perfectly good about it. It is something we are aware of and have on a (long) list of things to watch for.

–Loren

I don’t find the code I wrote unclear, but I definitely agree with you that yours is even clearer and that others could be confused about continue. I’m glad you learned something more about it by reading the doc!

–Loren

First, regarding the primary lesson from the column: Yes, the try / catch method seems like a robust method to deal with the issue of error handling. We all should be in favor of techniques that make code easy to maintain. Thanks for illustrating the technique. Plus, it takes fewer modules of code and fewer lines of code. All these are good.

Now for the unexpected detail: In your first (complicated) batch of code you have:

16    for k = 1:length(varargin)
17        if isscalar(varargin{k})
18            continue
19        end
20        nonscalarsizes{end+1} = int2str(size(varargin{k}));
21    end

At first, I couldn’t follow what was happening with the “if” statement and the “continue”. I thought the “continue” would take you out of the “if” statement.

Although I’ve criticized a few sections of MatLab documentation in the past, the “continue” section served very well in this case. The documentation was clear that the continue statement terminated this cycle of the “for” loop.

So, I was confused, I read the documentation and now I understand. Success!

But, I don’t think this coding technique is sound because many others who will read the code will also make the same assumption that I did. Isn’t it clearer to do a negative test? Something like this:

16    for k = 1:length(varargin)
17        if ~isscalar(varargin{k})
18            nonscalarsizes{end+1} = int2str(size(varargin{k}));
19        end
20
21    end

You even save a line of code.

What you are seeing is the difference between / and ./. Try x./sigma and you will see the output is also empty. For the slash operator, which is matrix division, the dimensions have to agree but for the point-wise ones, where we allow scalar expansion, we have the output the size of the nonscalar input. Empty is considered, with size 0×0, to not be a scalar (which has size 1×1) and therefore its dimensions propagate through.

–Loren

I use a message id when I use error because we use the id to help us show messages in Japanese for the Windows version of MATLAB for Japan.

I always try to use a message id when I add a warning since that is how users can selectively turn warnings on and off.

–Loren

EDU>> x = 10;
EDU>> mu = 5;
EDU>> sigma = [];
EDU>> expMuSig(x, mu, sigma)

ans =

[]

The function returns []. I went back and checked it. When x is scalar, sigma = [] and if I do

EDU>> x/sigma
??? Error using ==> mrdivide
Matrix dimensions must agree.

but if perform an array division

EDU>> x./sigma

ans =

[]

Could you explain what is happening.