Calling the error function does not print the line number in r2022b
39 次查看(过去 30 天)
显示 更早的评论
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.
1 个评论
Stephen23
2023-6-13
"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?
采纳的回答
Dominik Schuster
2023-3-14
编辑:Dominik Schuster
2023-3-14
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:
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.
5 个评论
Gabriele Gualandi
2023-11-7
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!
更多回答(5 个)
William Graves
2023-11-6
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:
0 个评论
John Paden
2023-11-13
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.
0 个评论
Rik
2022-9-29
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)
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.)
2 个评论
Rik
2022-9-29
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.
Xingwang Yong
2023-8-24
Yet another un-wanted feature. The bug report says it is fixed, but in R2023a it is still there.
1 个评论
Stephen23
2023-12-15
Not sure if the behavior is different with scripts, but this is the current behavior on this forum:
mytest()
function mytest()
a = 1+2;
error('hello world')
end
gwoo
2024-3-1
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.
1 个评论
Ronan Fleming
2024-5-10
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?"
另请参阅
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!