Native Command Error Handling

[theJasonHelmick]

Link to original: #261

[SteveL-MSFT]

Suggested change

	In the example below, `set -e` is not equivalent to `$ErrorActionPReference` for native commands.
	In the example below, `set -e` is not equivalent to `$ErrorActionPreference` for native commands.

[SteveL-MSFT]

should say "Will NOT continue script execution after failure", apply globally

[SteveL-MSFT]

Need to clarify what 0 and 1 means for those not familiar

[SteveL-MSFT]

some alignment issues with vertical bars

[ForNeVeR]

In Bash, it is possible to temporarily disable set -e by using command || true, e.g.

set -e
cat ./nonexistent || true
echo "Test" # will be written

From the specification, it is unclear whether a similar trick will work with $PSNativeCommandErrorAction. I believe it should be written explicitly.

[rkeithhill]

@ForNeVeR you would do this:

$PSNativeCommandErrorAction = $true
& {
    $PSNativeCommandErrorAction = $false
    cat ./nonexistent
    "Test" # will be written
}

cat ./nonexistent
"Will not get output"

The disabling of $PSNativeCommandErrorAction will only be valid for that scriptblock.

@theJasonHelmick When can we get this? Please let this ship in 7.2 - at least as an experimental feature!!! Maybe I should submit a PR to remove Start-NativeExecution from the PowerShell build scripts. I think the team isn't feeling the pain as much as the rest of us in the community. :-)

[joeyaiello]

@PowerShell/powershell-committee reviewed this and are okay to move forward with an experimental implementation based on this RFC.

However, it's not currently committed for 7.2. As such, we're adding the up-for-grabs label.

[rkeithhill]

Making this name longer seems like the wrong direction to go. Also, if it ends in ActionPreference then I would expect it to be of type [System.Management.Automation.ActionPreference] instead of [bool].

[ceztko]

I agree that the variable being boolean and the name ending with Preference sounds weird. The name is so long that Use gets lost while reading. PSNativeCommandErrorActionEnabled, PSEnableNativeCommandErrorAction may better highlight the implicit type of the variable. Still they are long names, though.

[rkeithhill]

One thing that concerns me is that we're kind of all over the place on terminology: NativeCommand, Program and the official get-command type is Application. That said, I'm not sure I like Application by itself e.g. Application "whoami.exe" ended with non-zero exit code 1. Application doesn't seem to be appropriate for cli utilities like whoami. Native command "whoami.exe" ended with non-zero exit code 1 seems OK.

[rkeithhill]

I think it would be helpful to see the arguments a a string. Or maybe rather than command path, show the "command line". Thoughts?

[rkeithhill]

Is the process ID of any use given that the process no longer exists?

[iSazonov]

I think it would be helpful to see the arguments a a string. Or maybe rather than command path, show the "command line". Thoughts?

This is not guaranteed after terminating of the process - an attempt to read a property of the Process class is likely to raise an exception. We can report reliably only current script line string or ProcessInfo as is.

Is the process ID of any use given that the process no longer exists?

This can be useful as correlation data with event logs.

[rkeithhill]

After talking this over with wg-engine group we decided that process id is useful for log correlation and arguments should not be recorded because it make contain passwords / api tokens.

[rkeithhill]

@theJasonHelmick The RFC does not mention anything about this being an experimental feature. I don't think that it needs to be experimental since it is "opt-in" via setting $PSNativeCommandUseErrorActionPreference to $true. Just wanted to get clarification on this. Do you agree?

[rkeithhill]

@theJasonHelmick Have you seen this ApplicationFailedException? This covers the case where a system exception is thrown when PS tries to run the application. My concern is that someone looking at the code base may be confused by seeing ApplicationFailedException and NativeCommandException.

[joeyaiello]

@rkeithhill even as an opt-in feature, it still needs to be marked as an experimental feature to denote to end-users that the design is not final and may change in the future.

Ideally, it should be code-fenced such that the opt-in isn't possible without the experimental feature turned on, but if the Maintainers agree with you that it's prohibitively difficult to do that, it should still have a placeholder experimental feature (where turning it off would do nothing) to denote the potential instability of the interface.

[joeyaiello]

@rkeithhill agreement that, especially given what's in the docs today for ApplicationFailedException ("Defines the exception that is thrown if a native command fails", it might make sense to rename NativeCommandException to something else.

@SteveL-MSFT is suggesting NativeCommandExitException, but we're open to other possibilities.

We're also referring this RFC to the Engine WG for review.

[iSazonov]

Suggested change

	- The default value is disabled (0) to maintain backward compatibility.
	- The default value is 0 (disabled) to maintain backward compatibility.

[iSazonov]

Why not re-use ApplicationFailedException if it is about exit?

[daxian-dbw]

The example itself doesn't support all cases

What example is it referring to? The if ($LASTEXITCODE -ne 0) { ... } one right above? If so, it's not clear to me how $? will affect that example, and can you maybe elaborate a bit more on how $LASTEXITCODE would be stale?

[JamesWTruher]

@theJasonHelmick - would you please confirm that the implemented experimental feature matches what is written here?

[per-oestergaard]

Is this now part of PowerShell as an experimental features (cannot find it in 7.2.2) or when will it come?

[rkeithhill]

It's in the current 7.3.0 preview - PSNativeCommandErrorActionPreference. After enabling the feature and restarting pwsh, try this:

whoami -xyzzy
get-date
& {
    $ErrorActionPreference = 'Stop'
    $PSNativeCommandUseErrorActionPreference = $true
    whoami -xyzzy
    get-date
}

[jtmoon79]

Noted in this Stackoverflow Answer.