{"id":442,"date":"2019-11-25T17:46:32","date_gmt":"2019-11-25T23:46:32","guid":{"rendered":"http:\/\/draith.com\/?p=442"},"modified":"2019-11-25T17:46:32","modified_gmt":"2019-11-25T23:46:32","slug":"2-great-experimental-features-in-core-7","status":"publish","type":"post","link":"https:\/\/draith.com\/?p=442","title":{"rendered":"2 Great Experimental Features in Core 7"},"content":{"rendered":"\n\n\n
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 \u2018PSNullConditionalOperators\u2019 and \u2018skip error check on web cmdlets\u2019. 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 \u2018Enable-ExperimentalFeature *\u2019 and restarting your PowerShell session. When you are done with your testing, you can always do a \u201cDisable-ExperimentalFeature\u201d to get your session back to normal.<\/p>\n
What exactly is \u2018PSNullConditionalOperators\u2019? This specifically refers to the \u2018&&\u2019 and \u2018||\u2019 operators, which deal with continuing or stopping a set of commands depending on the success or failure of the first command. The \u2018&&\u2019 operator will execute what is on it\u2019s right if the command on it\u2019s left succeeded, and conversely the \u2018||\u2019 operator will execute what is on it\u2019s right if the command on it\u2019s left failed. Probably the best way to picture this is with an example.<\/p>\n
<\/p>\n\n\n\n
Write-Host \u201cThis is a good command\u201d && Write-Host \u201cTherefore this command will run\u201d\n\nThis is a good command\n\nTherefore this command will run<\/code><\/pre>\n\n\n\n
The first write-host succeeded, and so the second write-host was run. Now, let\u2019s look at \u2018||\u2019.<\/p>\n\n\n\n
write-badcmdlet \"This is a bad command\" || Write-Host \u201cTherefore this command will run\u201d\nwrite-badcmdlet: The term 'write-badcmdlet' is not recognized as the name of a cmdlet, function, script file, or operable program.\n\nCheck the spelling of the name, or if a path was included, verify that the path is correct and try again.\n\nTherefore this command will run<\/code><\/pre>\n\n\n\n
Here we can see that the \u2018write-badcmdlet\u2019 cmdlet doesn\u2019t 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 \u2013 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.<\/p>\n\n\n\n
write-badcmdlet \"This is a bad command\" || Write-Host \u201cTherefore this command will run\u201d && \"And so will this one\"\n\n\n\n\nwrite-badcmdlet: The term 'write-badcmdlet' is not recognized as the name of a cmdlet, function, script file, or operable program.\n\nCheck the spelling of the name, or if a path was included, verify that the path is correct and try again.\n\nTherefore this command will run\n\nAnd so will this one<\/code><\/pre>\n\n\n\n
You can see how the 3rd<\/sup> command worked because the 2nd<\/sup> 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:<\/p>\n\n\n\n
notepad && \"Worked fine!\"\n\nWorked fine!\n\nnotepad2 && \"Worked fine!\"\n\n\n\n\nnotepad2: The term 'notepad2' is not recognized as the name of a cmdlet, function, script file, or operable program.\n\nCheck the spelling of the name, or if a path was included, verify that the path is correct and try again.\n\nnotepad2 || \"Failed!\"\n\n\n\n\nnotepad2: The term 'notepad2' is not recognized as the name of a cmdlet, function, script file, or operable program.\n\nCheck the spelling of the name, or if a path was included, verify that the path is correct and try again.\n\nFailed!<\/code><\/pre>\n\n\n\n
\u00a0<\/p>\n
Now on to the second experimental feature \u2013 and one that I find amazingly handy.\u00a0 Often times when you are working with RestAPIs or really any sort of web request, you are dealing with invoke-restmethod and invoke-webrequest.\u00a0 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.\u00a0 Consider this:\u00a0<\/p>\n\n\n\n<\/figure>\n\n\n\n
\n\nThat url doesn\u2019t 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 \u2018-SkipHttpErrorCheck\u2019 handles this. With this switch, a returned error code from these cmdlets will not return as an error. Combine this with \u2018-StatusCodeVariable\u2019 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!\n\n<\/p>\n\n\n\n<\/figure>\n","protected":false},"excerpt":{"rendered":"
![\"\"](\"http:\/\/draith.com\/wp-content\/uploads\/2019\/11\/shot1.png\")
<\/figure>\n\n\n\n![\"\"](\"http:\/\/draith.com\/wp-content\/uploads\/2019\/11\/shot2.png\")
<\/figure>\n","protected":false},"excerpt":{"rendered":"