PowerShell -ErrorAction: When Stop Beats Continue for Predictable Scripts

Use -ErrorAction Stop per call for try/catch, not a global preference

The practical rule is: keep the default Continue for interactive work, and add -ErrorAction Stop on the specific cmdlets you want to treat as fatal inside a script. That makes error handling predictable without changing global behavior for the whole session.

-ErrorAction is a common parameter. It controls how a cmdlet reports errors, not whether an error occurs. The default value for the parameter is Continue. That means non-terminating errors are written to the error stream and the pipeline keeps running.

How -ErrorAction and $ErrorActionPreference interact

Two settings influence error behavior. $ErrorActionPreference is a preference variable that sets a session-wide default. -ErrorAction is a per-invocation parameter that overrides the preference for that single call.

Precedence is: explicit -ErrorAction > $ErrorActionPreference > default Continue. The preference variable affects cmdlets that do not receive an explicit -ErrorAction.

Valid values you will see in about_CommonParameters are SilentlyContinue, Continue, Stop, Inquire, and Ignore. SilentlyContinue suppresses the error record and continues. Stop converts a non-terminating error into a terminating error that can be caught by try/catch. Continue writes the error and continues, which is the default.

Worked configuration for reliable error handling

Run the following in a PowerShell console as a regular user. No elevated rights are required. It demonstrates precedence without changing state.

# Show current session default
$ErrorActionPreference

# Per-call override: this call will not be affected by the preference
Get-Item -LiteralPath 'C:\nonexistent_path' -ErrorAction SilentlyContinue

# Per-call Stop makes the error terminating for this invocation only
try {
    Get-Item -LiteralPath 'C:\nonexistent_path' -ErrorAction Stop
}
catch {
    # Error is now catchable here
    Write-Host 'Caught terminating error from Get-Item'
}

Replace the literal path with a path you know does not exist on your machine. The first call uses SilentlyContinue, so no error record is emitted. The second call uses Stop, so the error becomes terminating and the catch block can handle it. The $ErrorActionPreference value is unchanged by either call.

For a pipeline, place -ErrorAction on the cmdlet that can fail, not on downstream cmdlets.

Get-ChildItem -Path 'C:\some\folder' -ErrorAction Stop | ForEach-Object { ... }

This ensures a failure in Get-ChildItem is caught, while ForEach-Object errors remain non-terminating unless you also set them.

Limits and where -ErrorAction does not help

Not all cmdlets honor -ErrorAction. Providers and legacy modules may implement their own error handling and ignore the common parameter. When a cmdlet does not respect -ErrorAction, Stop will not make the error terminating.

Terminating vs non-terminating is cmdlet-defined. -ErrorAction Stop can promote a non-terminating error to terminating, but it cannot make a cmdlet that always throws terminating errors non-terminating.

Setting -ErrorAction Stop can abort script execution abruptly. If resources such as files, registry keys, or connections are opened before the failing call, they may be left open unless you use try/finally or using statements for cleanup.

In PowerShell 5.1 the default $ErrorActionPreference is Continue, matching the per-call default. Confusion arises when scripts set $ErrorActionPreference globally and later rely on per-call values, or when modules change the preference without restoring it.

Common mistakes

• Setting $ErrorActionPreference = 'Stop' globally to force try/catch everywhere. This makes unrelated cmdlets terminate unexpectedly and is hard to reason about in shared modules.
• Assuming -ErrorAction SilentlyContinue means success. It hides errors, making failures invisible in logs and downstream logic.
• Placing -ErrorAction on the wrong command in a pipeline. The parameter applies only to the cmdlet it is attached to.
• Expecting -ErrorAction to suppress exceptions thrown by .NET methods called from PowerShell. It only affects cmdlet error records.

Check the result practically

Verify the supported values and defaults for your version with:

Get-Help about_CommonParameters

Compare preference vs per-call behavior by inspecting $ErrorActionPreference before and after a script block that sets it locally:

$ErrorActionPreference
{ $ErrorActionPreference = 'SilentlyContinue'; Get-Item 'C:\nonexistent' }
$ErrorActionPreference

The preference should be restored after the block ends if you used a local scope. If it is not, the script is leaking global state.

When you need deterministic error handling, prefer explicit -ErrorAction Stop on the risky call inside a try/catch with a finally block for cleanup, and avoid changing $ErrorActionPreference for the whole session.