In this blog post, I want to drill into a couple of very useful experimental features that are available in PowerShell 7 preview 6. The two features I want to dive into are ‘PSNullConditionalOperators’ and ‘skip error check on web cmdlets’. The former feature was available in preview5, and the latter was made available in preview 6. Both of these are (as of the writing of this blog) experimental features. In order to play around with these features, I suggest doing a ‘Enable-ExperimentalFeature *’ and restarting your PowerShell session. When you are done with your testing, you can always do a “Disable-ExperimentalFeature” to get your session back to normal.
What exactly is ‘PSNullConditionalOperators’? This specifically refers to the ‘&&’ and ‘||’ operators, which deal with continuing or stopping a set of commands depending on the success or failure of the first command. The ‘&&’ operator will execute what is on it’s right if the command on it’s left succeeded, and conversely the ‘||’ operator will execute what is on it’s right if the command on it’s left failed. Probably the best way to picture this is with an example.
Write-Host “This is a good command” && Write-Host “Therefore this command will run”
This is a good command
Therefore this command will runThe first write-host succeeded, and so the second write-host was run. Now, let’s look at ‘||’.
write-badcmdlet "This is a bad command" || Write-Host “Therefore this command will run”
write-badcmdlet: The term 'write-badcmdlet' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Therefore this command will runHere we can see that the ‘write-badcmdlet’ cmdlet doesn’t exist (if it does, we need to talk about your naming conventions), so the second command was run. This can replace 3 or 4 lines of code easily – you would normally have to do an if-else block to check the $? variable and see if it was true or false. You can also get fancy and chain these together for even more checks.
write-badcmdlet "This is a bad command" || Write-Host “Therefore this command will run” && "And so will this one"
write-badcmdlet: The term 'write-badcmdlet' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Therefore this command will run
And so will this oneYou can see how the 3rd command worked because the 2nd command ran successfully. Very handy, and dead simple to consolidate code. They even work with OS commands! Look at this example using notepad and the non-existent notepad2:
notepad && "Worked fine!"
Worked fine!
notepad2 && "Worked fine!"
notepad2: The term 'notepad2' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
notepad2 || "Failed!"
notepad2: The term 'notepad2' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Failed!
Now on to the second experimental feature – and one that I find amazingly handy. Often times when you are working with RestAPIs or really any sort of web request, you are dealing with invoke-restmethod and invoke-webrequest. One major pain point with these cmdlets is that if you get a non-200 error code back from the cmdlet, it returns an actual error object. Consider this:
That url doesn’t exist, but the way the error object is returned can be a massive pain! What if I want to know if it was a 404 vs a 500 vs a 403 and actually want to do something about it? Dealing with error objects is not the most intuitive, and I much prefer the way the new experimental feature ‘-SkipHttpErrorCheck’ handles this. With this switch, a returned error code from these cmdlets will not return as an error. Combine this with ‘-StatusCodeVariable’ and you can now act on the actual error without large try/catch blocks. You can use switch blocks to route properly based on status code without diving into error objects. This is a very welcome feature!
