Native Command Error Handling

[theJasonHelmick]

No description provided.

[rkeithhill]

I'd like to see the PS team dogfood the implementation of this feature by using it instead of the Start-NativeExecution function used in the PS build module.

[SteveL-MSFT]

This was one of the motivations of doing this feature so we can remove that helper function

[SteveL-MSFT]

Suggested change

	In production, often customers prefer that script execution stops when a non-terminating error
	In production, often customers prefer that script execution stops when any error, including non-terminating errors,

[SteveL-MSFT]

Include that on Windows, many native commands do not strictly follow the non-zero is error, so we may add a special list to handle those commands differently where known non-zero exit code is not treated as an error.

[mklement0]

@SteveL-MSFT, I suggest we not do that, because it adds complexity while providing little benefit: the "rogue" CLIs fall into two categories:

• True rogue CLIs that simply ignore exit codes and always return 0

  • There's nothing we can generally do to compensate for that, short of - brittlely - trying to analyze stderr output, which I don't think is worth doing.

• CLIs such as robocopy.exe that repurpose specific nonzero exit codes to communicate additional information about success conditions (while also using (other) nonzero exit codes to communicate failure).

• These exit codes are CLI-specific, and the user needs to know about them and handle them; while we could hard-code exceptions for the nonzero exit codes that signal success, the problems are:

  • Do we really want to code such exceptions for all utilities that ship with Windows (assuming there are others - I don't know)?
  • Users may expect the same magic to apply to all utilities, whether in-box or not.
  • Maintenance burden: What if utilities later introduce additional nonzero exit codes that aren't failures?

Instead, I think we should make it as easy as possible to ignore a nonzero exit code ad hoc, which can already be done, though it's not the most obvious solution:

# Call robocopy and ignore any failure that a nonzero exit code may trigger.
robocopy ... || @()

# ... now analyze $LASTEXITCODE

[essentialexch]

msiexec has two values that indicate success, but that a reboot is required (1641 and 3010), along with 0 also indicating success. That's the other one that I run into constantly (besides robocopy).

Discussed here: https://docs.microsoft.com/en-us/windows/win32/msi/error-codes

I'm sure there are more.

[mklement0]

Thanks, @essentialexch, that's good to know.

However, instead of getting into the hard-coded exception business, I suggest documenting such high-profile exceptions as part of a conceptual help topic dedicated to external-program calls: see MicrosoftDocs/PowerShell-Docs#5152

[SteveL-MSFT]

stderr not being interpreted as an error by $ErrorActionPreference was a new experimental feature added to 7.1

[SteveL-MSFT]

Suggested change

	which causes the shell to exit when a command fails. In addition, to ensure that an error is
	which causes the shell to exit when a command fails due to non-zero exit code. In addition, to ensure that an error is

[SteveL-MSFT]

I think it would be good to have an example script showing the difference in behavior between pipefail and w/o pipefail

[SteveL-MSFT]

Add that additional configuration may be enabled to disable pipefail if there is a customer need for it

[SteveL-MSFT]

Should move this to Considerations section

[SteveL-MSFT]

There's a mismatch here between Continue being default and line 83

[SteveL-MSFT]

Not really "no effect" as the error record is added to $Error

[SteveL-MSFT]

Suspend is not supported as it's only for workflows

[mklement0]

Worth mentioning the v7+ alternative based on the pipeline-chain operators:

# Note the need for $(...)
ls /no/such/path || $(throw "Command failed. See above errors for details") 

[mklement0]

Typo: "stream" is doubled.

[mklement0]

Perhaps it's worth creating a specific category for this, such as NativeFailure - not sure how adding an enum value would affect backward compatibility (at least in PowerShell code it shouldn't).

[mklement0]

I think it is implied by the current revision, but let me spell it out to see if my understanding is correct:

• Unlike bash's set -e, PowerShell will not (and should not) make the failure detection dependent on whether or not it is used in a conditional (e.g., as part of an if statement).

  • Unlike in POSIX-like shells, where conditionals act on exit codes, PowerShell's conditionals act on data, so it make sense to treat failure detection separately and to thereby avoid the rule complexity surrounding set -e.

• Like bash's set -e, PowerShell will bypass failure detection if a failure occurs in a non-final segment of a pipeline chain, so as to allow overriding $PSNativeCommandErrorAction ad hoc.

Examples:

$PSNativeCommandErrorAction = 'Stop'

# SHOULD fail, if `ls` reports a nonzero exit code.
if (-not ($name = /bin/ls nosuch.txt))  {
  $name = 'default.txt'
}

# Should NOT fail, because || is used to explicitly handle the failure:
/bin/ls nosuch.txt || 'default.txt'

[joeyaiello]

Closing as this is superceded by #277