Calling the error function does not print the line number in r2022b

In r2021a I can generate an error inside a function and the error message will be printed in the Command Window along with the stack trace and relevant line numbers:

r2021a

In r2022b, the stack trace is displayed with the error line number on the caller script, but the line number error is not displayed on the callee script:

r2022b

Please review this behavior and fix in upcoming updates.

[Stephen23]

"Please review this behavior and fix in upcoming updates."

Agreed.

How did this it-really-is-not-a-feature decision get past anyone who actually uses MATLAB?

Answer 1

[Dominik Schuster]

FIY, I filed a bug report on this behavior a few days ago.

I got the response as stated below. Bottom line:

It's not a bug, i'ts a feature - however Mathowrks staff themselves seems somewhat divided on the topic.

My two cents:

• The line should be thrown as i feel the error command is used by somehwat experienced developers, usually to supply other developers with more detailed info on accidental misuse etc... So the line no. and easy acces of the relevant code area/file in the editor is certainly of help, even if only pointing out the line containing the error command.
• Not throwing the line makes for a different workflow debugging Exceptions generated by the error command, as opposed to Exceptions thrown by Matlab itself.
• It might be a philosophical thing, so maybe the best solution would be an optional argument that switches behavoir of the error command in this regard.
• The workaround provided is not very satisfactory - only recommended in Workspace and does not for errors thrown from a catch block.

Excerpt of Mathworks support response:

I am writing in reference to your Technical Support Case 06092067 regarding 'error command does not throw code line to workspace'.

Thank you for coming up with this issue. However, this is an intentional change and not a bug.

The justification for the change is that the first line number/link appearing in the "Error using…" preamble is seldom, if ever, the place where the mistake was made. Most often, the mistake was with the use, or invocation, of the function that errored.

A workaround is to view the stack of the MException object. The first frame will continue to point to the throw site (line number):

>> MException.last.stack(1)

ans =

struct with fields:

file: 'D:\MatlabFiles\readFile.m'

name: 'readFile'

line: 3

Please be aware that "MException.last" should only be used from the Command Window and not within a function:

https://www.mathworks.com/help/releases/R2022b/matlab/ref/mexception.last.html#budqx4k-3

I apologize for the inconvenience this is causing on your end! There is also an existing internal request to revert that behavior. I am linking this Service Request with our internal documentation, such that you are automatically notified, if this request is considered in one of the upcoming Updates or Releases of the software.

[Rik]

Please post a comment here if and when this behavior is reverted. I suspect I would otherwise miss that change as well.

[Ed Callway]

Yup this is a terrible change.

Now to find the line where an error() message was posted I have to include a unique text error message, then go to the text editor and search for it - for many years before I could just click on the line shown.

Of course I can't include the line number in the error() message as any edit above will invalidate it.

I include an error() message at the end of almost every switch and if/elseif stack so unhandled cases are flagged, so this happens a lot especially during development and debugging.

Complete waste of every developer's time every day!

PLEASE restore a way to simply report the error() line number without invoking random lines of needless MException magic incantations. Simpler, less code, less obtuse is ALWAYS better.

[EFB]

Please, please revert this as soon as possible! The ability of entering the workspace directly where the error was triggered is one of the main benefits of Matlab over alternatives such as Python. This is perhaps the most important feature that enables me to be much more productive with Matlab than with the alternatives. In other words, if this is not reverted, I see myself switching to Python sooner or later.

[Gabriele Gualandi]

This is inconvenient. To me, it's logical that the first thing to do in order to debug, is to start from the line generating the error!

[Jeremy P]

yes, very bad "feature", please revert to old way

Answer 2

[William Graves]

Agreed this is quite annoying. It seems like, for user-defined functions, the line number should always be displayed.

As a workaround, I've been using assert(0, ...) instead of error(...). This results in a printout like this that at least shows the line number where it occurred:

Answer 3

[John Paden]

The bug may not occur at the line where the failure occurs, but that line of code is almost ALWAYS helpful in figuring out what failed. I definitely hope Mathworks reverts this feature of removing the line number. I do not think it is helpful to remove potentially useful information and the line number is printed on the same line as the filename so it does not even clutter the output. It is so nice to be able to just click on the line number and have it jump directly to where the error occurred.

Answer 4

[Rik]

I personally use my own customized versions of error and warning. They take an options struct as the first argument to determine where the message should be printed.

options = struct('fid',1); % Print to command window.
call_a_test(options)

this is a function
[2022-09-29 07:37:44] Error: This generates an error
> In a_test (line 3)
  In call_a_test (line 2)
  In LiveEditorEvaluationHelperEeditorId (line 2)
  In fevalMatlab (line 0)
  In fevalJSON (line 0)

Error using a_test
This generates an error

Error in call_a_test (line 2)
a_test(options)

Error in solution (line 2)

The intention is that the printed text is stable across all versions of Matlab and Octave. I know this is not exactly the solution you're looking for, but it might be useful to you nonetheless.

(Note that what you perceive as a bug might be an intentional design choice you disagree with.)

[Sergio Roche]

Thanks for sharing your implementation. I can see you are covering about 20 years of MATLAB history. I will wait and see if staff can comment on it being a design change or a bug.

[Rik]

I will probably publish these functions to the file exchange at some point. If and when I do, there will be a test matrix included. It is indeed my goal to cover every version since Matlab 6.5 (which is 20 years old by now).

If my answer helped you, please consider marking it as accepted answer.

I don't know if you can expect a staff member to comment, unless you contact support explicitly. Most comments posted by staff members are posted under their own capacity, not as an official statement from Mathworks.

Answer 5

[Xingwang Yong]

Yet another un-wanted feature. The bug report says it is fixed, but in R2023a it is still there.

[Stephen23]

Not sure if the behavior is different with scripts, but this is the current behavior on this forum:

mytest()

Error using solution>mytest
hello world

function mytest()
a = 1+2;
error('hello world')
end

Answer 6

[gwoo]

I just ran into this this past week. I made a work around that would fprintf the same info, like the line number along with hyperlinks, before it rethrows the error message. I also submitted for support for it and shared this very page's link.

The response I got was interesting and in my environment, I'm not able to try it out but hopefully many of you can and provide the strong feedback Mathworks needs to hear:

As we work through these concerns, I would like to offer a recommendation that may provide some immediate relief. The MATLAB R2024a pre-release version has already reverted this functionality, restoring the display of line numbers when exceptions are triggered by the 'error()' function. While I cannot guarantee this feature will be present in the final R2024a release, testing the Prerelease could offer a temporary solution and an opportunity to provide further feedback on its implementation. You may follow the link below to download the R2024a Prerelease.

[Ronan Fleming]

Anyone who writes a lot of matlab code uses a breakpoint at the line where the error is thrown to re-run the code and debug in situ before it is too late. Removing the default option to see where the error was is daft, but not as daft as at least providing an option on the error function to turn it on or off. It should be on by default. I agree with the sentiment of Stephen:

"How did this it-really-is-not-a-feature decision get past anyone who actually uses MATLAB?"