How to make assert() debug break?
3 views (last 30 days)
I attached my solution. Not sure why it's not the default behavior.
function assert1( b )
if nargin < 1
b = 0;
disp( 'Assertion failed.' );
dbstop in assert.m at 11;
dbclear in assert.m at 11;
ST = dbstack;
if length( ST ) > 1
ST = ST(2);
fl = ST.file;
ln = ST.line + 1;
cmd = [ 'dbstop in ' fl ' at ' int2str(ln) ];
eval( cmd )
Steven Lord on 5 Jul 2022
Based on Jan's description (I have not read the code) you'd also want to think about what this does if you call assert1 at the MATLAB prompt, on the last line of a file, on the last line of a function, inside an eval call, in a P-coded file (I think this one might work), via mexCallMATLAB in a MEX-file, in a deployed application, ...
IMO there are certain functions that inherently require interactivity and so users won't be surprised if those functions behave interactively. input, uigetfile, and keyboard are examples of these. But if you call a function that requires interactivity in a function that doesn't, or if you make a function require interactivity that users' mental model says shouldn't require interactivity, that can be annoying to the point of unusability.
Imagine if (for example) the plot function prompted users for the X and Y data every time it was called. You couldn't use it in a program you intended to run unattended. Is users' mental model for assert more like input (where you expect it to require interactivity) or more like plot (start it running and let it do its thing)? To me having assert drop into debug mode would be quite annoying.
Besides, there is a way to get assert to stop and drop you into debug mode without requiring any changes to the functionality of assert or changes to code that calls assert. Set an error breakpoint. If the assert triggers it will cause an error which will be caught by the error breakpoint.