Suppress line number display in error message

Is there a way to suppress the line number display when using the error command? For example, the following statement in a function: error('ERROR: I do not like argument %s',arg); displays an extra line showing where the error line occurred. ??? Error using ==> (file name) at (line number) ERROR: I do not like argument (argument) Can one stop the first line (with three question marks) from being generated? I want to stop execution (regardless of how deeply this function is buried), but the end user doesn't need to know where the error was generated.

[Daniel Dolan]

I appreciate the answer thus far--I've learned a lot about MATLAB exception handling in the process. To illustrate the problem, suppose you have a file reader of some kind that is called by an analysis routine that is launched by a graphical interface callback.

   GUI > analysis > reader

For modularity, I would normally create each of these function independently so they can easily be transferred to other programs (especially the reader).

Let's say that for whatever reason, the user provides an invalid file. Maybe it's the wrong format, or perhaps there is simply something wrong that can't be found until the reader begins to scan the file. Good practice dictates that the reader function should throw an error to let the user know something is wrong, but end users don't need to know where in the code the error was thrown. That information can be misleading (the code isn't faulty, the user made a mistake), frustrating (the user may have p-code, so they can't view the source anyway), or dangerous (the user may try to make changes to "fix" the problem).

MATLAB has ways to add information to the exception, but I haven't found a way to reduce the output to only the developed-provided message. I like the ability to identify the exception for use with lasterr, but something like a "stop" command would be handy. If can break out of a particular function using a return statement in the catch block, but that will lead to more errors in the calling function(s).

Answer 1

[Image Analyst]

Yes. Use try/catch and spit out whatever error message you want:

try
  % Some code that throws an exception....

catch ME
  errorMessage = sprintf('Error in function BlahSnafuFubar().\n\nError Message:\n%s', ME.message);
  fprintf(1,'%s\n', errorMessage);
  uiwait(warndlg(errorMessage));
end

[Daniel Dolan]

I've tried something like this, but if the error occurs in a function nested within other function, the catch block doesn't stop execution.

[Image Analyst]

No, it warns the user. But it doesn't spit out any line number. If you want to do things differently once it exits the function then you'll have to return some kind of error or status code and bubble your way back out, like Daniel says. There is a "quit" command but it also shuts down MATLAB, not just your m-file.

Answer 2

[Daniel Shub]

In your exact use case, where you only supply an error message and no identifier, I don't think you can. If you are willing to provide an identifier than you can do something like

throwAsCaller(MException(MSGID, 'ERROR: I do not like argument %s', arg))

This will move you one step up in the stack. In order to make it all the way to the top you would need

try
  mycode;
catch ME
  throwAsCaller(ME);
end

at each level.

[Daniel Dolan]

I can fake an identifier (matlab:unnamed), but that's only part of the problem. I'm looking for a quiet way to terminate execution, even when the error occurs in a nested function call. The throwAsCaller method eliminates some of the extraneous line numbers, but still reveeals where the error occurred. I'm trying to hide that level of detail from the end user: they only need a message to tell them what they did wrong.

[Daniel Shub]

There seem to be three ways of dealing with it. You can wrap any user space function in the try-catch and then use a throwAsCaller to suppress the error information. Better would be to do go input argument checking on user space functions to prevent errors from occurring later. Finally you might be able to do some nasty hacking, overloading of builtin functions and meta programming to automatically uninformatively error your way out.

Answer 3

[Arthur]

Use getReport instead. For instance

try
%something
catch me
   errorstring= getReport(me,'basic')
uiwait(warndlg(errorstring));
end

[Daniel Shub]

This has the same "problem" as all the other answers, it doesn't return you immediately to the prompt

Answer 4

[Daniel Shub]

I will try this as a new answer. Just wrap everything (or almost everything) in a try-catch...

function varargout = reader(varargin)
  errMsg = (inputchecker(varargin));
  if ~isemtpy(errMsg)
     disp(errMsg);
     return;
  end
  try
    varargout = p_reader(varargin);
  catch ME
    errMsg = disectME(ME);
    disp(errMsg);
    return;
  end
end

where inputchecker checks the inputs as best as possible, p_reader is your current reader function, and disectME deals with the different errors that may happen in p_reader.

[Daniel Dolan]

If reader is called by analysis, the return statement in the try-catch block will take execution back to analysis. Since the outputs of reader won't be set correctly, another error will be generated there.

One could put everything in the analysis and GUI functions inside a try-catch block, passing the error message/ID back to that point for custom display with a clean exit. That might be tricky in a large function hierarchy, but it's an option.

[Daniel Shub]

It only has to be done at the user space level. If the user only deals with the GUI, then wrap all the callbacks of the gui in a try-catch. Realistically this is a bad idea. You will make your code completely unmaintainable since you will have no idea where errors are occurring. You need to put the checks in to prevent errors from happening.