A PowerShell script loops over hundreds of inputs calling a cmdlet for each. It must not stop at the first failure, but at the end it must report exactly which ones failed. How do you capture those errors, and why is $Error not a good enough answer?

## The requirement: keep going, but remember Bulk automation has a shape that neither pure fail-fast nor pure ignore-errors satisfies: attempt every input, and finish with a precise, machine-readable list of what failed. PowerShell gives you two idiomatic ways to build that. ## Pattern one: -ErrorAction SilentlyContinue with -ErrorVariable ```powershell foreach ($path in $paths) { Get-Item -Path $path -ErrorAction SilentlyContinue -ErrorVariable +fileErrors | Out-Null } "Failures: {0} of {1}" -f $fileErrors.Count, $paths.Count $fileErrors | ForEach-Object { $_.Exception.Message } ``` Three details make or break this pattern: **The name has no dollar sign.** `-ErrorVariable` takes the *name* of a variable to create, not the variable itself. Writing `-ErrorVariable $fileErrors` passes the current (probably empty) value of that variable as the name, and the errors land somewhere you did not expect. The same convention applies to the sibling common parameters `-OutVariable`, `-WarningVariable` and `-InformationVariable`. **The leading + appends.** Without it, `-ErrorVariable` *replaces* the variable's contents on every single invocation, so after the loop you hold only the errors from the final iteration. `+fileErrors` appends, accumulating across the whole loop. This is the single most common bug in the pattern. **SilentlyContinue, not Ignore.** `Ignore` throws the error away outright — it is not recorded in `$Error`, and there is nothing left to report. If you are capturing errors, `SilentlyContinue` is the value you want: no console noise, full retention. ## Pattern two: per-item try/catch ```powershell $failures = [System.Collections.Generic.List[object]]::new() foreach ($path in $paths) { try { Get-Item -Path $path -ErrorAction Stop | Out-Null } catch { $failures.Add([pscustomobject]@{ Input = $path Reason = $_.Exception.Message Type = $_.Exception.GetType().FullName }) } } ``` This is more code but strictly more control. The loop variable is in scope inside the `catch`, so you record precisely which input failed without relying on the error record to identify it; you can shape the report exactly as your downstream consumer wants; and you can branch on the exception type — retry a transient timeout, skip a permanently missing item. Note what would go wrong without the loop: `-ErrorAction Stop` on a single call that processes the whole collection aborts at the first failure and never touches the rest. Stop belongs *inside* the iteration, not around it. ## Why $Error is the wrong tool here `$Error` is an automatic variable holding a session-wide history of error records, newest first at `$Error[0]`. It is genuinely useful — at an interactive prompt, after something went wrong, `$Error[0] | Format-List -Force` is the fastest way to see everything about the last failure. As the basis of a report it fails on several counts: - **It is shared.** Every error the session produced is in there, including ones from before your loop started and ones from unrelated code. You cannot tell yours apart without extra bookkeeping. - **It is capped.** `$MaximumErrorCount` defaults to 256, so a long bulk run silently discards the oldest records — the earliest failures, usually the ones that explain the pattern. - **It is order-only.** It records sequence, not association with an input, so mapping records back to the items that produced them is guesswork. - **It is mutable state you do not own.** `$Error.Clear()` before a loop makes it slightly more usable and is a common trick, but you are still relying on nothing else in the session writing to it. `-ErrorVariable` gives you exactly the records from exactly the calls you asked about, with no cap and no sharing. ## Reporting and the exit contract Once you hold the failure list, decide what "the job failed" means. Common practice for a scheduled or CI-invoked script is: emit the failures as structured objects (or write them to a file), and end with a non-zero exit code when the list is non-empty, so the scheduler can see the run as failed. A useful refinement is a threshold — if more than some proportion of items fail, the assumption behind the run is probably wrong and it should abort rather than plough on for another hour producing the same error a thousand times. ## A note on $? `$?` is a related but much weaker signal: a boolean reporting whether the *immediately preceding* command succeeded. It is fine for a quick guard directly after a call, but it is overwritten by the very next command, so it cannot accumulate anything and is no substitute for capturing records.