-
Notifications
You must be signed in to change notification settings - Fork 133
Native Command Error Handling #277
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from 14 commits
717787c
1fa25ed
5d04d21
a985804
c03f3df
1a38126
d29e4c3
77f46e2
bef6778
fce539d
e274268
177a002
98a1055
ac7edb8
15f408d
84b263b
6fb05cd
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
@@ -0,0 +1,322 @@ | ||||||
--- | ||||||
RFC: RFC00XX | ||||||
Author: Jason Helmick | ||||||
Status: Draft | ||||||
Area: Core | ||||||
Comments Due: 10/31/2020 | ||||||
--- | ||||||
|
||||||
# Native Command Error Handling | ||||||
|
||||||
PowerShell scripts using native commands would benefit from being able to use error handling | ||||||
features like those used by cmdlets. | ||||||
|
||||||
## Motivation | ||||||
|
||||||
In PowerShell by default, script processing continues when non-terminating errors occur. This is a | ||||||
benefit when expecting non-terminating errors in normal execution such as non-responsive computers | ||||||
from a list. This default behavior is controlled with the preference variable | ||||||
`$ErrorActionPreference` default of `Continue`. | ||||||
|
||||||
In production, often customers prefer that script execution stops when a non-terminating error | ||||||
occurs. This is particularly true in CI where the preference is to fail fast. PowerShell currently | ||||||
supports customers with this ability by setting the `$ErrorActionPreference` variable in the script | ||||||
to `Stop`. | ||||||
|
||||||
```Powershell | ||||||
$ErrorActionPreference = 'Stop' | ||||||
``` | ||||||
|
||||||
Native commands usually return an exit code to the calling application which will be zero for | ||||||
success or non-zero for failure. However, native commands currently do not participate in the | ||||||
PowerShell error stream. Redirected `stderr` output is not interpreted the same as the PowerShell | ||||||
error stream as many native commands use `stderr` as information/verbose stream and thus only the | ||||||
exit code matters. Users working with native commands in their scripts will need to check the | ||||||
execution status after each call using a helper function similar to below: | ||||||
|
||||||
```Powershell | ||||||
if ($LASTEXITCODE -ne 0) | ||||||
{ | ||||||
throw "Command failed. See above errors for details" | ||||||
} | ||||||
``` | ||||||
|
||||||
Simply relaying the errors through the error stream isn't the solution. The example itself doesn't | ||||||
support all cases as `$?` can be false from a cmdlet or function error, making `$LASTEXITCODE` | ||||||
stale. | ||||||
|
||||||
In POSIX shells, terminating execution when a command has an error is enabled via executing `set -e` | ||||||
in the session. In addition, to ensure that an error is returned if any command in a pipeline fails, | ||||||
POSIX shells address this via executing `set -o pipefail` in the session. | ||||||
|
||||||
This specification proposes a similar idea, but adapted to the PowerShell conventions of preference | ||||||
variables and catchable, self-describing, terminating error objects. This proposal adds the | ||||||
equivalent functionality of `set -e -o pipefail` (abbreviated to `set -eo pipefail`) to stop | ||||||
execution and return an error if any command in a pipeline fails. | ||||||
|
||||||
The specification and alternative proposals are based on the | ||||||
[Equivalent of bash `set -e` #3415](https://github.com/PowerShell/PowerShell/issues/3415) | ||||||
committee review of the associated | ||||||
[pull request](https://github.com/PowerShell/PowerShell/pull/3523), and | ||||||
[implementation plan](https://github.com/PowerShell/PowerShell-RFC/pull/88#issuecomment-613653678) | ||||||
|
||||||
## Specification | ||||||
|
||||||
This RFC proposes a preference variable to enable errors produced by native commands to be | ||||||
PowerShell errors, so that failures will produce error objects that are added to the error stream | ||||||
and may terminate execution of the script without added boilerplate. | ||||||
|
||||||
The specification proposes similar functionality to the common POSIX shell configuration | ||||||
`set -eo pipefail`. | ||||||
|
||||||
- `set -u` - returns an error if any variable has not been previously defined. | ||||||
theJasonHelmick marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
- `set -e` - instructs to immediately exit if any command has a non-zero exit status. | ||||||
- `set -o pipefail` - prevents errors in the pipeline from being masked. The return code for the | ||||||
non-zero error is returned for the entire pipeline. | ||||||
|
||||||
### set -u/ Set-StrictMode | ||||||
|
||||||
In the example below, `set -u` behavior of `bash` is shown followed by the proposed behavior for | ||||||
PowerShell. This is not part of this proposal, but added for clarity. | ||||||
|
||||||
theJasonHelmick marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
```bash | ||||||
bash-3.2$ cat file | ||||||
#!/bin/bash | ||||||
/bin/echo "Without set -u : No output - No error is produced" | ||||||
/bin/echo "$firstname" | ||||||
/bin/echo "" | ||||||
/bin/echo "With set -u : Equivalent to Set-StrictMode -Version 2.0" | ||||||
set -u | ||||||
/bin/echo "$firstname" | ||||||
``` | ||||||
|
||||||
```output | ||||||
bash-3.2$ file | ||||||
Without set -u : No output - No error is produced | ||||||
|
||||||
With set -u : Equivalent to Set-StrictMode -Version 2.0 | ||||||
/Users/jasonhelmick/natcmdbash/strict: line 10: firstname: unbound variable | ||||||
``` | ||||||
|
||||||
```powershell | ||||||
PS> cat ./file.ps1 | ||||||
/bin/echo "Without Set-StrictMode -version 2.0 : No output - No error is produced" | ||||||
/bin/echo "$firstname" | ||||||
/bin/echo "" | ||||||
/bin/echo "With Set-StrictMode -version 2.0 : Equivalent to set -u" | ||||||
Set-StrictMode -version 2.0 | ||||||
/bin/echo "$firstname" | ||||||
``` | ||||||
|
||||||
```output | ||||||
PS> ./file.ps1 | ||||||
Without set -u : No output - No error is produced | ||||||
|
||||||
With Set-StrictMode -version 2.0 : Equivalent to set -u | ||||||
InvalidOperation: /Users/jasonhelmick/natcmdbash/psstrict.ps1:9 | ||||||
Line | | ||||||
9 | /bin/echo "$firstname" | ||||||
| ~~~~~~~~~~ | ||||||
| The variable '$firstname' cannot be retrieved because it has not been set. | ||||||
``` | ||||||
|
||||||
### set -e/ $ErrorActionPreference | ||||||
|
||||||
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. | |
In the example below, `set -e` is not equivalent to `$ErrorActionPreference` for native commands. |
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should say "Will NOT continue script execution after failure", apply globally
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to clarify what 0 and 1 means for those not familiar
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some alignment issues with vertical bars
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?