$? doesn't change in case of parsing error

[dronkoff]

Steps to reproduce

1..5 | buggy_call
$?

The result is $False and this is expected

1..5 | $_
$?

The result is $True and this is not expected

Expected behavior

1..5 | $_
$?

The result of $? should be $False because previous statement results in an error.

Environment data

PS C:\temp> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.15063.296
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.15063.296
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Notes

From Tom Nolan words:

The problem here is that $? Is set during the CheckActionPreference method when an error is encountered. https://github.com/PowerShell/PowerShell/blob/02b5f357a20e6dee9f8e60e3adb9025be3c94490/src/System.Management.Automation/engine/runtime/Operations/MiscOps.cs

However, CheckActionPreference is not executed until the AST has been parsed (https://github.com/PowerShell/PowerShell/blob/02b5f357a20e6dee9f8e60e3adb9025be3c94490/src/System.Management.Automation/engine/parser/Compiler.cs) and PowerShell actually attempts to execute the command, stepping through the pipeline.

[MaximoTrinidad]

At the same, this issue can be replicated in PowerShell Core (v6 Beta).

Please, I may suggest to also post this incident at Windows PowerShell UserVoice site at: https://windowsserver.uservoice.com/forums/301869-powershell/category/148044-powershell-engine

This way the Windows PowerShell team can assist in taking a look at this issue.

:)

[BrucePay]

PowerShell compiles the entire text of a script at once so a parse error anywhere in the block prevents the entire block from being executed. QED you can't catch or detect a parse error in the code being parsed since that code is never run. @mklement0 's example of 1/0 is not a parse error. (It was treated as a parse-time error in PowerShell V1 but it's been a runtime error since then.)

[iSazonov]

Really in second example a pipeline is created but interrupted and the code that set QuestionMarkVariableValue don't executed.
Default value for QuestionMarkVariableValue is True - so we see True as result.

I believe it is by design - (1) as @BrucePay said it is not problem for script because no command will be executed - that's why we should use try-catch. (2) for interactive session using $? is pointless while you see parser error - I believe we shouldn't worry about QuestionMarkVariableValue value in that case.

[mklement0]

@iSazonov: My bad (I have little insight into how PS parsing works at this point; other comment deleted too):

I missed that if the code is placed in a script, the entire script won't be executed, so it is treated as parse error.

Interactively, this can be shown by placing $? on the same line, in which case $? is never executed:

1..5 | $_; $?   # $? never executes

Calling a script that fails to parse from another script DOES set $? to $False, so the interactive behavior - though unexpected - is less of an issue, as you say.

On a related note, however: from the calling script's perspective, shouldn't an attempt to call a script with parse errors result in a terminating error that the calling script must therefore handle with try / catch?

[iSazonov]

@mklement0 Please don't remove history. You can strike out - use double tildes around the words.

[iSazonov]

My understanding is that $? is from v1 time and today a prefered way is try / catch

[mklement0]

Good point re history, will do.

$? still has (and, I presume, will continue to have) its place for reflecting non-terminating errors, but a parse error is arguably severe enough to warrant a terminating one so that the calling script aborts by default.

Yes, you can detect the parse error with try / catch (the exception inside the error record is of type [System.Management.Automation.ParseException]), but by default the calling script continues to run.

Note that an ordinary non-terminating error - such as reported by Get-Item /Nosuch can not be caught with try / catch.

From what I can tell, this problematic hybrid behavior - non-terminating-error behavior by default, terminating-error behavior with try / catch - applies to the following kinds of errors:

• parse errors in an invoked script ([System.Management.Automation.ParseException])
• runtime errors such as 1 / 0 ([System.Management.Automation.RuntimeException])
• parameter-binding exceptions such as Get-Content -NoSuchParam ([System.Management.Automation.ParameterBindingException])
• .NET methods that report an exception, such as[int]::Parse('foo') ([System.Management.Automation.MethodInvocationException])

Note sure if there are more.

As I've suggested in #3359 (comment), perhaps it makes more sense to treat these as terminating errors.

[iSazonov]

In PowerShell context "terminating" error is a error "terminating current pipeline".
As previously mentioned, we have confusion with terminating and non-terminating errors.

[rkeithhill]

My understanding is that $? is from v1 time and today a prefered way is try / catch

$? is still useful in scripts to see if a command encountered a non-terminating error. Say I'm copying a bunch of files recursively from one dir to another. If there is a file or folder I don't have permission to the copy will not 100% succeed. I can test for this condition by checking $?.

Of course, you can tell PowerShell to convert the non-terminating error to a terminating error with -ErrorAction Stop and then use try/catch. Which one a scripter chooses comes down to preference - what a scripter is more comfortable with.

[mklement0]

@rkeithhill:

Absolutely, but my point was that the error types I've mentioned (parse in callee/runtime/parameter binding/method invocation):

• behave like non-terminating errors by default
• though in their ability to be caught irrespective of the current $ErrorActionPreference value they behave like terminating ones - this is what I meant by "hybrid".

It seems to me that making these error types regular terminating errors not only resolves the inconsistency, but also makes more sense:
These types of errors are not the ones you want to tolerate as partial failures while the script goes on to still perform (partially) useful things.

For instance, if I call Get-Content -NoSuchParameter in a script, I want that script to break by default.

With respect to the general distinction between terminating and non-terminating errors and to what extent PS and its cmdlets play by the official rules, I've tried to summarize the state of affairs in this SO answer a while back.

[Update with the benefit of hindsight: I was arguing for a script-terminating error, as opposed to a statement-terminating one; the former term is not official, but reflects the de-facto behavior summarized in this doc issue.]

[dronkoff]

$?  
   Contains the execution status of the last operation. It contains
   TRUE if the last operation succeeded and FALSE if it failed

From the end user point of view it doesn't matter what type of error he sees on the screen. He sees red text and an error description but $? returns $true. He decides "ok, look like this thing doesn't work, I wont use it" and then he goes to:

$error.Clear()
... -ErrorAction SilentlyContinue
if($error.Count -gt 0) 

Looks like it would be great to change the default value to $false.
If no operation was executed then how status of it's execution can be $true.

[lzybkr]

I do question the value of making a change here. $? is most useful when it's not obvious if there was an error or not, and it's especially useful in automation.

Parse errors that occur during automation should be exceedingly rare - it basically means you didn't test your script before deployment.