Changing Matlab error message

All, my issue is this. I have 1 script that calls a function that contains many subfunctions. If one of those functions fail, I want everything to end, but I dont want the error message stack output to the command window, only the error string I specify.

I am already checking for the errors that can occur within the function, I'm just trying to get a handle on how to cleanly report to the command window that something went wrong. The end user wont care about where in the file the error is, only the error message I am outputting instead.

Alternativly, if there is a way I can simply stop all function execution programatically without using the "error" command and hence avoiding the error stack info, that would be even better.

Thanks

Answer 1

[Sean de Wolski]

Use try/catch to catch the exception (error). Then throw your own error of choice inside the catch block.

try
  your_fun
catch ME
  error('Something')
end

For your second question, possibly. You could put the try/catch around the entire parent function contents. Then when any of the functions inside this function error, you catch it and return instead of erroring.

function fooParent
try
  stuff
  more stuff

    other stuff
  catch 
    return %leave

end
function subfun1

end
function subfun2

end

Now when anything errors in fooParent or it's subfunctions etc, we just return.

[Daniel Shub]

You might want to use throwAsCaller, which will strip the stack information, instead of creating a new error. Note that this type of error handling makes debugging a real nightmare.

[Sean de Wolski]

@Daniel, I agree with the "makes debugging a nightmare part". Though:

dbstop if caught error

helps a lot.

Answer 2

[Philip]

Thanks for the thoughts. I've considered use try/catch, my issue is this though.

Essentially I have a function I've written that contains many subfunctions. A seperate user will call my top level function and one of the same functions inside. Suppose its as defined below:

function Math function Addition(addition inputs)

     return
return

For example, the user has some script "Example.m" that would then call: Math('Addition',addition inputs). When an error occurs in my functions, I want to report an error to the command window (without using the stack info as we all talked about above) but also prevent any further execution of their "Example.m" script.

Hopefully thats a bit clearer in what Im trying to accomplish. Thanks again for the feedback.

[Sean de Wolski]

Why does try/catch and what I suggested above not address exactly this?

[Philip]

It will catch the error in the function I have written, but not end the script execution that called my function. Unless I've somehow misconstrued how return works or what you've described above, the calling script would still continue on.

The script is being written by somneone else and I have no control over the entries there other to know that my function of functions will be called within it.

Thanks again

[Sean de Wolski]

Ah. That is not possible then. Their script would either have to try/catch your function or you'll have to rethrow() the error.

[Daniel Shub]

I think it is throwAsCaller might be better than rethrow since throwAsCaller will gobble the stack.

[Sean de Wolski]

Yeah I suppose. Or just

error(ME.message)

[Daniel Shub]

Unless of course ME.message is '', in which case error will not throw an error. Why do you like the old system?

[Sean de Wolski]

@Daniel, to be honest, I haven't given it much thought.

For the most part I try to write code that is safe guarded against exceptions and when they occur I fix them rather than try/catch them.

Actually, right now is the first time I'm working on a project (See my Friday Fun with Eval question) that includes evaluating user code and needs to be heavily safeguarded against exceptions.

This conveniently coincides with the release of the Unit Testing Framework in R2013a. What I've been doing is the following: inside of a Test method in a class than inherits from matlab.unittest.TestCase, I try the user code and catch the exception. Then fail the test with an assertion which stops the remainder of the test and provides the diagnostic from the exception.