Suppress line number display in error message

조회 수: 14 (최근 30일)
Daniel Dolan
Daniel Dolan 2012년 11월 3일
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.
  댓글 수: 1
Daniel Dolan
Daniel Dolan 2012년 11월 6일
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).

댓글을 달려면 로그인하십시오.

답변 (4개)

Image Analyst
Image Analyst 2012년 11월 3일
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
  댓글 수: 2
Daniel Dolan
Daniel Dolan 2012년 11월 5일
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
Image Analyst 2012년 11월 5일
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.

댓글을 달려면 로그인하십시오.


Daniel Shub
Daniel Shub 2012년 11월 5일
편집: Daniel Shub 2012년 11월 5일
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.
  댓글 수: 2
Daniel Dolan
Daniel Dolan 2012년 11월 5일
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
Daniel Shub 2012년 11월 6일
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.

댓글을 달려면 로그인하십시오.


Arthur
Arthur 2012년 11월 6일
Use getReport instead. For instance
try
%something
catch me
errorstring= getReport(me,'basic')
uiwait(warndlg(errorstring));
end
  댓글 수: 1
Daniel Shub
Daniel Shub 2012년 11월 6일
This has the same "problem" as all the other answers, it doesn't return you immediately to the prompt

댓글을 달려면 로그인하십시오.


Daniel Shub
Daniel Shub 2012년 11월 6일
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.
  댓글 수: 2
Daniel Dolan
Daniel Dolan 2012년 11월 6일
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
Daniel Shub 2012년 11월 6일
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.

댓글을 달려면 로그인하십시오.

카테고리

Help CenterFile Exchange에서 Startup and Shutdown에 대해 자세히 알아보기

태그

제품

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by