{"id":72152,"date":"2015-07-15T00:01:00","date_gmt":"2015-07-15T00:01:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/2015\/07\/15\/use-powershell-strict-mode-for-debugging\/"},"modified":"2019-02-18T09:46:59","modified_gmt":"2019-02-18T16:46:59","slug":"use-powershell-strict-mode-for-debugging","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/use-powershell-strict-mode-for-debugging\/","title":{"rendered":"Use PowerShell Strict Mode for Debugging"},"content":{"rendered":"

Summary<\/b>: Ed Wilson, Microsoft Scripting Guy, talks about using strict mode in Windows PowerShell for debugging purposes.<\/span>\nMicrosoft Scripting Guy, Ed Wilson, is here. One of the cool things about Windows PowerShell is that it can take being ignored or being used carelessly and sloppily, and it still seems to work fine. I mean, in the old days with VBScript, it was common to use Option Explicit to force you to declare all of the variables that you were going to use in the script. In Windows PowerShell, no one seems to do this…at all.\nThe bad thing is that if I run a script (say in the Windows PowerShell ISE) and the variable increments, if I do not set it to a known number (say 0), or even if I initialize it as $null, each time the script runs, the value of the variable changes. This can be bad for consistent results.\nSo when I have a script that is important and that I want to make sure will always run consistently, I like to initialize my variables—that is, declare them and set them to an initial value.\nHere is what I am talking about. The first time I run the following code, I print “less than four” several times:<\/p>\n

PS C:\\><\/p>\n

For ($i = 1; $i -le 5; $i++)<\/p>\n

    {<\/p>\n

     $a<\/p>\n

     $a += $i<\/p>\n

    If ($a -le 4) {“Less than four”}}<\/p>\n

0<\/p>\n

Less than four<\/p>\n

1<\/p>\n

Less than four<\/p>\n

3<\/p>\n

6<\/p>\n

10<\/p>\n

PS C:\\> \nBut the second time I run the script, I never reach that If<\/b> line because the value of $a<\/b> starts off greater than four:<\/p>\n

PS C:\\><\/p>\n

For ($i = 1; $i -le 5; $i++)<\/p>\n

    {<\/p>\n

     $a<\/p>\n

     $a += $i<\/p>\n

    If ($a -le 4) {“Less than four”}}<\/p>\n

15<\/p>\n

16<\/p>\n

18<\/p>\n

21<\/p>\n

25<\/p>\n

PS C:\\> \nThe way to correct the problem is to initialize $a<\/b> as equal to 0 <\/b>(zero) at the beginning of the script. Now, every time I run the script, I get the correct output:<\/p>\n

PS C:\\><\/p>\n

 $a = 0<\/p>\n

For ($i = 1; $i -le 5; $i++)<\/p>\n

    {<\/p>\n

     $a<\/p>\n

     $a += $i<\/p>\n

    If ($a -le 4) {“Less than four”}}<\/p>\n

0<\/p>\n

Less than four<\/p>\n

1<\/p>\n

Less than four<\/p>\n

3<\/p>\n

6<\/p>\n

10<\/p>\n

PS C:\\><\/p>\n

 $a = 0<\/p>\n

For ($i = 1; $i -le 5; $i++)<\/p>\n

    {<\/p>\n

     $a<\/p>\n

     $a += $i<\/p>\n

    If ($a -le 4) {“Less than four”}}<\/p>\n

0<\/p>\n

Less than four<\/p>\n

1<\/p>\n

Less than four<\/p>\n

3<\/p>\n

6<\/p>\n

10<\/p>\n

PS C:\\> \nIt might be useful to be able to force Windows PowerShell to tell me that I am using an uninitialized variable. I can easily do this by using Windows PowerShell and the Set-StrictMode<\/b> cmdlet.<\/p>\n

Using the Set-StrictMode cmdlet<\/h2>\n

Here is a simple script, I used yesterday in More PowerShell Script Tracing and Strict Mode<\/a> that will help illustrate using Set-StrictMode<\/b>:<\/p>\n

SimpleTypingErrorNotReported.ps1<\/p>\n

$a = 2
$b = 5
$d = $a + $b
“The value of `$c is: $c”<\/p>\n

The Set-StrictMode<\/b> cmdlet can also be used to enable strict mode. It has the advantage of being scope aware. Whereas the Set-PSDebug<\/b> cmdlet applies globally, if the Set-StrictMode<\/b> cmdlet is used inside a function, it enables strict mode for only the function.<\/p>\n

There are two modes of operation that can be defined when using the Set-StrictMode<\/b> cmdlet. The first is –version 1<\/b>, which behaves the same as the Set-PSDebug -Strict<\/b> command except that scope awareness is enforced. This is shown here:<\/p>\n

PS C:\\> Set-StrictMode -version 1
PS C:\\> C:\\fso SimpleTypingError.ps1
The variable ‘$c’ cannot be retrieved because it has not been set.
At C:\\fso\\SimpleTypingError.ps1:4 char:28
+ ‘The value of $c is: ‘ + $c <<<<
    + CategoryInfo          : InvalidOperation: (c:Token) [], RuntimeException
    + FullyQualifiedErrorId : VariableIsUndefined
PS C:\\>\nThe Set-StrictMode<\/b> cmdlet is not able to detect the uninitialized variable contained in the expanding string that is shown in the SimpleTypingErrorNotDetected.ps1 script.\nWhen –version 2<\/b> is enacted, the technique of calling a function like a method is stopped. The AddTwoError.ps1 script passes two values to the add-two<\/b> function via method notation. Because method notation is allowed when calling functions, no error is normally generated.\nBut method notation of passing parameters for functions only works when there is a single value to pass to the function. To pass multiple parameters, function notation must be used, as shown here:<\/p>\n

add-two 1 2\nAnother way to call the add-two<\/b> function correctly is to use the parameter names when passing the values, for example:<\/p>\n

add-two -a 1 -b 2\nEither of the two syntaxes would produce the correct result. The method notation of calling the function displays incorrect information but does not generate an error. An incorrect value being returned from a function with no error being generated can take a significant amount of time to debug. The method notation of calling the add-two<\/b> function is used in the AddTwoError.ps1 script, and it is shown here:<\/p>\n

add-two(1,2)\nWhen the script is run and the Set-StrictMode -version 2<\/b> command has not been enabled, no error is generated. The output seems to be confusing because the result of adding the two variables $a<\/b> and $b<\/b> is not displayed:<\/p>\n

PS C:\\> C:\\fso\\AddTwoError.ps1
1
2
PS C:\\>\nWhen the Set-StrictMode -version 2<\/b> command is entered and the AddTwoError.ps1 script is run, an error is generated. The error that is generated states that the function was called as if it were a method. The error points to the exact line where the error occurred and shows the function call that caused the error. The function call is preceded with a plus sign (+<\/b>) followed by the name of the function, followed by four arrows that indicate what was passed to the function. The error message is shown here:<\/p>\n

PS C:\\> Set-StrictMode -version 2
PS C:\\> C:\\fso\\AddTwoError.ps1
The function or command was called as if it were a method. Parameters should be
 separated by spaces. For information about parameters, see the about_Parameters Help topic.
At C:\\FSO\\AddTwoError.ps1:7 char:8
+ add-two <<<< (1,2)
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : StrictModeFunctionCallWithParens
PS C:\\>\nThe complete AddTwoError.ps1 script is shown here:<\/p>\n

AddTwoError.ps1<\/p>\n

Function add-two ($a,$b)
{
 $a + $b
}<\/p>\n

add-two(1,2)\nWhen you specify Set-StrictMode<\/b> for Windows PowerShell version 2.0, it checks the following items:<\/p>\n