Though it's been four years since the above question was asked, since no one answered, yet, I will give it a try. I recently ran into the same dummy error and looked at the code of iGetCurrentStack. It's some thing like this: try error('dummy error'); catch e return some properties of e; end
Apparently, it first throws the dummy error, then catches it, obtains the stack list of calls from the error object and returns the list - the call stack. Hence the function name.
I personally don't like such code. It's strange to find it in Mathworks own code. I don't think that a try-catch should be part of any normal operation. Try-catch is designated to handle errors, not as an if-then-else GOTO statement. I wonder if there is no better way to access the calls stack?
In any rate, if you too hit it, it only means that you were using, like myself, the debugging event
dbstop if caught error
You may try, at that break point, to Continue. Though, within a parfor, parallel runs don't always behave as expected... Debugging a parfor is still as painful as it was four years ago. All errors are caught and re-thrown at the parfor line, therefore loosing any information about the actual error location. Well, trying to debug if caught error lands right on this mine.
