{"id":277,"date":"2008-11-17T15:35:19","date_gmt":"2008-11-17T15:35:19","guid":{"rendered":"https:\/\/blogs.mathworks.com\/desktop\/2008\/11\/17\/adding-debugging-code-without-changing-your-code\/"},"modified":"2008-12-03T14:53:02","modified_gmt":"2008-12-03T14:53:02","slug":"adding-debugging-code-without-changing-your-code","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/community\/2008\/11\/17\/adding-debugging-code-without-changing-your-code\/","title":{"rendered":"Adding Debugging Code Without Changing Your Code"},"content":{"rendered":"


\nI’d like to welcome guest blogger Ken Atwell from the MATLAB Technical Marketing team. Ken will occasionally be blogging here on the Ken & Mike on the MATLAB Desktop<\/a> blog.
\n<\/i><\/p>\n

As helpful as facilities like breakpoints and MATLAB\u2019s interactive environment are, I\u2019m sure that many of us still use \u201cold school\u201d debugging techniques from time to time. Chief among these is scattering disp<\/tt> statements throughout your code and then combing through the output to try to spot where something has gone awry. It is ad hoc for sure, but it gets the job done.<\/p>\n

This comes with an obvious downside, though, namely that you will later need to remove all of the debugging code. Not an impossible task, especially if you have a baseline under source control to \u201cdiff\u201d against, but it\u2019s an error-prone step nevertheless. One of the more embarrassing moments in my professional career was when I left a debugging statement in the production code. Overnight, the regression test engine unceremoniously barfed on the nightly build and I came into the office the next day to a chorus of jeers. All in good fun and little harm done, but that prompted me to look for alternatives.<\/p>\n

Enter the conditional breakpoint, a seemingly unlikely ally. If you have not used conditional breakpoints to date, I encourage you to experiment with them. They are very useful when you need to run through a breakpoint many times before your application gets into (or approaches) an error state. <\/p>\n

The trick to using a conditional breakpoint is to simply appreciate that the condition will always<\/i> be evaluated, but the breakpoint will only be triggered if the condition evaluates to some non-zero value. The condition can be \u201cx>0<\/tt>\u201d, or \u201cmin(x{:})>0<\/tt>\u201d, or even \u2026 drum roll \u2026\u201cfprintf(\u2018x is %d\\n\u2019, x)<\/tt>\u201d. Basically, it can be any expression that evaluates to some value. Unfortunately, this means we cannot (directly) use disp<\/tt>, since disp<\/tt> does not return a value. That is, you\u2019ll get an error if you try to do something like \u201cy=disp(x)<\/tt>\u201d.<\/p>\n

So, let\u2019s try using an \u201cun-conditional\u201d breakpoint to display a string. Set a breakpoint inside your favorite piece of code. Then, right-click that breakpoint and choose \u201cSet\/Modify Condition\u201d.<\/p>\n

<\/a><\/div>\n

Make the condition \u201cfprintf(\u2018Hello, World!\\n\u2019)<\/tt>\u201d. Now run that code and you\u2019ll see \u201cHello, World!\u201d written to the Command Window. We did this without modifying the source code itself, so we don\u2019t need to remember to back the change out later. The conditional breakpoint is also shown in yellow in the Desktop, distinguishing it nicely from normal (red) breakpoints.<\/p>\n

<\/a><\/div>\n

Right about now you are probably saying, \u201cbut my program stopped running at that breakpoint, I wanted my program to continue!\u201d Now we need to concern ourselves with the conditional itself. doc fprintf<\/tt><\/a> will remind us that the length of the string is returned. In our case, this was 14 (on my Windows box). This is not zero, so the debugger stopped execution. We need to augment our condition to always evaluate to false. Something like \u201c0==fprintf(\u2018Hello, World!\\n\u2019)<\/tt>\u201d will do the trick. Here, the value returned by fprintf<\/tt>, 14, will be compared against zero (0). The values are not equal, so this expression evaluates to logical false (zero). This means the debugger will continue to run the program. <\/p>\n

Make this change to your conditional breakpoint and rerun your program. It still displays the message we inserted, but the program now runs through the breakpoint as desired.<\/p>\n

Wait\u2026but what if you are printing something that might actually be of length zero, meaning 0==0<\/tt>, meaning logical true, meaning my program stops-when-I-don\u2019t-want-it-to? Actually, this can\u2019t happen here because the \u2018\\n<\/tt>\u2019 (newline) guarantees at least one character of output. But, if you don\u2019t have such a guarantee in your fprintf<\/tt>, you can guard against the zero length case with the following funny-looking expression, which always evaluates to false:<\/p>\n

0 == fprintf(something) && 0<\/pre>\n
The \u201c&& 0<\/tt>\u201d performs a logical AND to zero, guaranteeing a false (0) evaluation overall, meaning the debugger will never break at this breakpoint.<\/p>\n
Using techniques like this, one can temporarily and non-destructively inject nearly any behavior into their application.  <\/p>\n
If you\u2019ve ever used conditional breakpoints in an unconventional way, be it in MATLAB or other applications, we\u2019d love to hear about it and learn from your experience and creativity.<\/p>\n

\n-by Ken Atwell, The MathWorks
\n<\/i><\/p>\n","protected":false},"excerpt":{"rendered":"
\nI’d like to welcome guest blogger Ken Atwell from the MATLAB Technical Marketing team. Ken will occasionally be blogging here on the Ken & Mike on the MATLAB Desktop blog.<\/p>\n
As helpful as… read more >><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[33,9],"tags":[],"_links":{"self":[{"href":"https:\/\/blogs.mathworks.com\/community\/wp-json\/wp\/v2\/posts\/277"}],"collection":[{"href":"https:\/\/blogs.mathworks.com\/community\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.mathworks.com\/community\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.mathworks.com\/community\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.mathworks.com\/community\/wp-json\/wp\/v2\/comments?post=277"}],"version-history":[{"count":0,"href":"https:\/\/blogs.mathworks.com\/community\/wp-json\/wp\/v2\/posts\/277\/revisions"}],"wp:attachment":[{"href":"https:\/\/blogs.mathworks.com\/community\/wp-json\/wp\/v2\/media?parent=277"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.mathworks.com\/community\/wp-json\/wp\/v2\/categories?post=277"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.mathworks.com\/community\/wp-json\/wp\/v2\/tags?post=277"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}