Errors in listener callbacks
显示 更早的评论
I have an app built in MATLAB App Designer. the underlying code utlizes events and listeners. my problem is this: Whenever an error occurs in the code, the app needs to know about this. when the error occurs in the code itself, there are built in "catch" commands that notify the GUI.
However, when an error occurs in one of the listener callbacks, there is some built in mechanism that replaces the error with a warning. Instead of getting an error message we get a warning: "error occurred during execution of listener callback" and a description of the error message.
Is there a way to cancel this mechanism? to let the errors in listener callbacks become actual error messages? or maybe a way to notify the app in case of a warning? something like try catch that includes warnings?
many thanks
Nathan
采纳的回答
> Is there a way to cancel this mechanism? to let the errors in listener callbacks become actual error messages?
No, there isn't an off-switch to this behavior.
> or maybe a way to notify the app in case of a warning?
It's unclear what listeners you are refering to but I'll assume they were added by the developer of the app rather than by app-designer. One idea is to wrap the listener's callback function within a try/catch and to take some action within the catch block when there is an error. However, warnings are not caught by the try-block.
Another idea is to use lastwarn to clear the last-warning-history at the beginning of the listener's callback and then to query lastwarn again at the end of the callback to determine if a warning was thrown.
Neither of these potential solutions would catch warnings that are thrown prior to or after reaching the callback function.
lastwarn('') % clear last warning
% < function code goes here >
[msg, id] = lastwarn();
if ~isempty(msg)
% take action on warning
end
5 个评论
Klont
2024-2-8
@Adam Danz Do you know what might be the reason MATLAB treats errors in listener callbacks as warnings?
Why not let the coder decide? I wonder.
Seems straightforward enough:
- They could type "error" if they want an error and "warning" when they want a warning.
- Or simply use a "try/catch me" inside the listener callback and convert any error that might occur to a "warning(me.message)" to achieve the current behavior. Easy-peasy. The other way around, converting a warning to an error inside the listener callback, seems impossible.
I don't understand the point of this language design decision at all.
Do you have any insights, perhaps?
Thanks,
Jacob
Adam Danz
2024-2-13
> Do you know what might be the reason MATLAB treats errors in listener callbacks as warnings?
Treating errors in listener callbacks as warnings helps to maintain the stability and continuity of the event handling system. In event-driven programming, listeners respond to events such as changes in properties, user interactions, or other triggers. If an error occurs within a listener callback and it is treated as a hard error, it could interrupt the event processing flow, potentially leaving the system in an inconsistent state following an early termination.
By treating these errors as warnings, MATLAB allows the event processing to continue while also providing feedback in the form or warnings. This design prioritizes the robustness of the application and the user interface and prevents a single faulty listener from disrupting the entire system.
One way to detect and react to warnings that occur duing a listener callback is to clear the last warning at the top of the callback and query the last warning at the end of the callback or wherever the warning is most probable within the callback. If the lastwarning is not empty, you can rethrow the warning as an error.
Thanks for your reply, Adam.
However, what you explain is the well known distinction between errors and warnings, i.e., stopping the flow of execution or just showing a message, respectively.
It doesn't explain why Mathworks decided to treat errors that happen in callbacks as warnings.
As coders, we have a simple way of converting an error in to a warning by catching it in a try/catch block. So we can decide if the "single faulty listener" should "disrupt the entire system" or not. This decision depends on what this fault is. It's not at all dependent on whether it happened in a callback or not.
Rethrowing warnings as errors is much more complicated. Especially when they happen in callbacks, because if i'd catch the lastwarn inside the callback function, I can't re-throw it as an error because someone decided that errors in callback are warnings.
This means that I'd have to use this lastwarn hack everywhere in the code that might trigger the callback. This could be dozens of places where I'd have to repeat the same boilerplate code.
To me, this seems inconsistent, inconvenient, unnecessary, and frankly, a blunder of design.
But perhaps I'm missing something?
Adam Danz
2024-2-18
I get where you're coming from, and I can see how this behavoir might feel like a head-scratcher. "Why" questions about long-established decisions can be tough to address. While I can't shed light on the historical 'why' behind this particular design choice, I could offer suggestions.
> we can decide if the "single faulty listener" should "disrupt the entire system" or not
I'm not sure that I follow this argument without a clarifying use case example. Listener callbacks have their own workspace so even if a listener callback would throw an error it wouldn't affect or disrupt any processes outside of that workspace. When there is an error within a listener callback, execution stops at that line which is a disruption to the processes within that workspace.
Try/catch statements still function within listener callbacks, although they can't be used to rethrow an error. They are still an effective way to detect and react to errors within the listener callback.
Here's an example.
I've created a faulty listener that updates the color of a marker any time the axes limit change. However, the marker no longer exists which causes an invalid or deleted object error in the listener callback.
I've caught the error and displayed the error message as red text along with a beep to simulate a MATLAB error.
Run this from a script and then manually drag the axes. Make sure your speakers are on.
figure
ax = axes;
h = plot(.5,.5,'+','MarkerSize',40,'LineWidth',5);
addlistener(ax, {'XLim', 'YLim'}, 'PostSet', @(~,~)listenerFcn(h));
delete(h)
function listenerFcn(h)
% Responds to changes to axis limits
try
h.Color = rand(1,3);
catch ME
% Simulate error
beep
fprintf(2,[ME.message,newline])
end
end
You'll see a burst of successive beeps along with a stack of error messages.
Nathan Blanc
2024-2-18
编辑：Nathan Blanc
2024-2-18
更多回答（1 个）
You can use keyboard in testing and debugging phase. Just a workaround. It's annoying I need to remove them when releasing.
try
% Listener function code
catch ME
keyboard
end
类别
在 帮助中心 和 File Exchange 中查找有关 Environment and Settings 的更多信息
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!
Translated by 
