{"id":11774,"date":"2016-04-20T06:00:09","date_gmt":"2016-04-20T13:00:09","guid":{"rendered":"https:\/\/www.sapien.com\/blog\/?p=11774"},"modified":"2016-04-29T19:22:38","modified_gmt":"2016-04-30T02:22:38","slug":"setting-conditional-breakpoints","status":"publish","type":"post","link":"https:\/\/dev.sapien.com\/blog\/2016\/04\/20\/setting-conditional-breakpoints\/","title":{"rendered":"Setting Conditional Breakpoints"},"content":{"rendered":"

Applies to PowerShell Studio 2016, PrimalScript 2016, and later.<\/strong><\/p>\n

\n

I write lots of scripts \u2014 for production, for research, for testing, and for demonstrations. And, inevitably, I hit a bug. I’m actually relieved when I do, because no code is perfect and I’d rather find the bugs before my users do. In fact, I make sure the content in my test database is full of oddities so it’s as close to the real world as possible.<\/p>\n

When you are debugging with a large test sample, like a database or directory, the default line breakpoints are not sufficient. I can hit a line numerous times before I get to the condition that breaks it. And, I don’t want to spend my time repeatedly banging on the F10 (step over) and F11 (step into) keys until I hit the offending condition.<\/p>\n

In PowerShell Studio 2016 and PrimalScript 2016, you can create and edit line, function, and variable breakpoints, and beyond that, you can set conditions for breaking. For example, I don’t want to break on line 32 every time it runs. I want to break when the $ID variable has a value of 9999 or only when the Set-Widget function runs and $ID is 0.<\/p>\n

Good old line breakpoints<\/h2>\n

Line breakpoints break just before the line of code with the breakpoint runs. Because most debuggers support line breakpoints, we’re very accustomed to using them. But, they might not be most efficient, so before you use a line breakpoint, consider whether a function or variable breakpoint might be a better choice.<\/p>\n

One of the nice things about line breakpoints is that they’re easy to see. You can see the big red dot beside the breakpoint on line 24 in this image. But if you want to break when the Set-Maximum function runs \u2014 not just when it’s called on line 24, consider a function breakpoint.<\/p>\n

\"function<\/a><\/p>\n

Use Function Breakpoints<\/h2>\n

A function breakpoint breaks right before the first line of code in the function runs. It actually breaks on the first curly brace in the function script block.<\/p>\n

If the function has BEGIN, PROCESS, and END blocks, a function breakpoint breaks on the first curly brace of the BEGIN block, then on the first curly brace of the PROCESS block, and again on the first curly brace of the END block.<\/p>\n

\"a<\/a><\/p>\n

The breakpoint does not break on the function declaration \u2014 when PowerShell reads the function into memory. It breaks only on the function call \u2014 where the function actually runs. So, if you have defined a function in a script, but the function doesn’t run, the function breakpoint is not triggered.<\/p>\n

Also, by default, a function breakpoint breaks every time the function runs, which might be handy, depending on your use case.
\n 
\nTo set a function breakpoint in PowerShell Studio:<\/strong><\/p>\n

    \n
  1. Click Home and, in the Run group, click Breakpoints<\/strong> \/ Set Function Breakpoint<\/strong> or Edit Breakpoints<\/strong>.
    \n    \"Click<\/a>\n<\/li>\n
  2. Select a function from the Function drop-down menu. You can also specify a file if you’re debugging with multiple files in a module or project.
    \n    \"specify<\/a><\/p>\n

    You can’t see the function breakpoint \u2014 there’s no big red dot in your script \u2014 but it’s effective.
    \n    \"You<\/a><\/p>\n

    And, the Edit Breakpoints<\/strong> dialog box display shows that it’s created and enabled.
    \n    \"the<\/a><\/p>\n

    TIP : I always use the Edit Breakpoints dialog to create, enable, disable, and delete my breakpoints. It displays all of the breakpoints in the session and reminds when that I create a breakpoint twice, instead of changing a breakpoint. To create a function breakpoint in Edit Breakpoints, click the “cube+” icon in the upper left corner.<\/li>\n<\/ol>\n

    Use Variable Breakpoints<\/h2>\n

    Variable breakpoints are my favorites. They break when the variable value is used (“read”), is changed (“write”), or either (“ReadWrite”).
    \n 
    \nTo set a variable breakpoint:<\/strong><\/li>\n

      \n
    1. Click Home and, in the Run group, click Breakpoints<\/strong> \/ Set Variable Breakpoint<\/strong>.
      \n 
      \n-or-
      \n 
      \nIn the Edit Breakpoints dialog, in the upper left corner, click the “square+” icon.<\/li>\n

       <\/p>\n

    2. Select a variable from the Variable drop-down menu.\n

      You can also type the variable name. Technically, you’re supposed to enter only the variable name without the ‘$’, but PowerShell Studio is wonderful, so if you forget and type the ‘$’, PowerShell Studio ignores it.<\/p>\n

      \"Create<\/a><\/li>\n

    3. From the Mode box, select Read<\/strong> (break whenever the variable value is read), Write<\/strong> (break when the variable value changes), or ReadWrite<\/strong> (both).<\/li>\n

      Like a function breakpoint, you won’t see a big red dot in your script to indicate a variable breakpoint, but you can see it in the Edit Breakpoints dialog box. (See why I like that dialog so much?)<\/p>\n

      For example, in this script, a write-mode variable breakpoint on ‘n’ is triggered on line 26, when the value of $n changes to the next value in the $numbers array. But, it is not triggered on line 28, when $n is read, but not changed. If I need a different behavior, I can change the mode of the breakpoint to Read or ReadWrite.<\/p>\n

      \"a<\/a>\n<\/ol>\n

      Create conditional breakpoints<\/h2>\n

      Variable and function breakpoints are very valuable, but conditional breakpoints are the extreme time-saver \u2014 an uber-breakpoint.<\/p>\n

      To set a conditional breakpoint:<\/p>\n