A PowerShell script runs an external program such as git inside a try block. The program fails and prints its error text, but the catch block never runs and the script carries on. Why do external programs behave differently from cmdlets, and how should the script detect the failure?

## Two different failure protocols PowerShell's error handling is built around one object type: the `ErrorRecord` written to the error stream. `-ErrorAction`, `$ErrorActionPreference`, `-ErrorVariable`, `$Error` and `try/catch` are all machinery around that object. An external program — `git`, `robocopy`, `docker`, `kubectl`, `msbuild` — participates in none of it. It is a separate operating-system process, and it obeys the ancient process contract instead: - **stdout** — its normal output, which PowerShell captures as a stream of strings. - **stderr** — a second text stream, conventionally used for diagnostics. - **exit code** — an integer returned when the process ends; zero conventionally means success. PowerShell records that integer in the automatic variable `$LASTEXITCODE`, and sets `$?` to `$false` when the code is non-zero. That is the whole of the signal. Because a non-zero exit produces no error record, `try/catch` has nothing to catch, `$ErrorActionPreference = 'Stop'` has nothing to escalate, and `-ErrorAction Stop` cannot even be applied — an external program does not accept PowerShell common parameters, so `git push -ErrorAction Stop` simply hands `git` two more arguments it does not understand. ## The explicit check The pattern that works on every PowerShell version: ```powershell git push origin main if ($LASTEXITCODE -ne 0) { throw "git push failed with exit code $LASTEXITCODE" } ``` Two cautions. `$LASTEXITCODE` reflects the most recent *native* command only, and it is overwritten by the next one — so check it immediately, before any other external call, and capture it into a local variable if you need it later. And `$?` is even more fragile: it reflects only the immediately preceding command, cmdlet or native, so an intervening `Write-Host` destroys it. In a script that shells out repeatedly, wrap the check once: ```powershell function Invoke-Native { param([scriptblock]$Command) & $Command if ($LASTEXITCODE -ne 0) { throw "native command failed with exit code $LASTEXITCODE" } } ``` ## PowerShell 7.4 and $PSNativeCommandUseErrorActionPreference Modern PowerShell narrows the gap. The preference variable `$PSNativeCommandUseErrorActionPreference` — introduced as an experimental feature in PowerShell 7.3 and no longer experimental in 7.4 — makes a native command that exits non-zero produce an error that honours `$ErrorActionPreference`. With it enabled and the preference set to `Stop`, a failing `git` call becomes a catchable terminating error like any cmdlet failure. Check the value in your own environment rather than assuming it, and remember it does not exist at all in Windows PowerShell 5.1. Any script expected to run on both should keep the explicit `$LASTEXITCODE` check, which behaves identically everywhere. ## stderr is not failure The second half of this trap: text on stderr does **not** mean the program failed. Plenty of tools use stderr for progress and informational output precisely because it keeps stdout clean for pipeable data — `git` writes clone and push progress there, `ffmpeg` writes essentially everything there. Judging success by "did it print to stderr" produces false alarms constantly. The inverse also bites. In Windows PowerShell, redirecting a native command's stderr into the error stream with `2>&1` turns those lines into error records — and under `$ErrorActionPreference = 'Stop'` an ordinary progress message can then abort the script. Scripts that were fine interactively fail as soon as someone captures their output. If you need the combined text, capture it as strings rather than routing it through the error stream. ## Not every non-zero code means failure Exit-code conventions are per-tool, not universal. `robocopy` is the standard example: it uses a bit-mapped exit code where values below 8 report what it did — 1 means files were copied, 3 means copied plus extras — and only 8 and above indicate real failures. A blanket `-ne 0` check treats a perfectly successful robocopy run as a catastrophe. When you wrap a tool, encode *that tool's* notion of success: ```powershell robocopy $src $dst /E if ($LASTEXITCODE -ge 8) { throw "robocopy failed with exit code $LASTEXITCODE" } ``` ## Why this matters in CI The consequence of getting this wrong is not a noisy log — it is a green build that shipped nothing. A deployment script that runs six external tools and checks none of their exit codes will report success while every step failed, because the only thing PowerShell itself decided was that it reached the end of the file. Explicitly propagating native failure — and ending the script with a non-zero exit code of its own — is what makes the pipeline honest.