In PowerShell, what is the difference between throw and Write-Error, and when would you choose each inside a function?

## Two ways for your code to say "that failed" PowerShell distinguishes terminating from non-terminating errors, and as the *author* of a function you choose which one you emit. `throw` and `Write-Error` are the two doors. ## throw `throw` raises a terminating error. Execution of the current pipeline stops immediately and PowerShell unwinds until it finds a `catch` block; if none exists, the error reaches the top and the script ends. ```powershell function Get-Config { param([string]$Path) if (-not (Test-Path $Path)) { throw "Config file not found: $Path" } Get-Content $Path } ``` Throwing a bare string is idiomatic and readable, but note what the caller receives: PowerShell wraps a thrown string in a `System.Management.Automation.RuntimeException`, so a caller cannot filter it with a meaningful typed `catch`. If callers need to distinguish your failure from every other failure, throw a real exception instead: ```powershell throw [System.IO.FileNotFoundException]::new("Config file not found: $Path") ``` ## Write-Error `Write-Error` constructs an `ErrorRecord` and writes it to the error stream. It is a *report*, not a halt: ```powershell function Test-Thing { Write-Error 'something went wrong' 'this line still runs' } ``` Calling `Test-Thing` prints the error **and** emits the string. Three side effects come with it: the automatic variable `$?` is set to `$false`, the record is prepended to `$Error`, and — crucially — the caller keeps control of what happens next. A caller who wants your reported failure to be fatal writes `Test-Thing -ErrorAction Stop`; a caller doing bulk work writes `-ErrorAction SilentlyContinue -ErrorVariable +failures` and carries on. `Write-Error` also accepts richer input than a message string: `-Message`, `-Category`, `-ErrorId`, `-TargetObject` and `-ErrorRecord` let you hand the caller something worth inspecting programmatically. `-TargetObject` in particular is how you tell the caller *which* item failed, which matters a lot in loops. ## Choosing between them The rule of thumb interviewers want to hear: - **Non-terminating (`Write-Error`)** when the failure is scoped to one item and the rest of the work is still meaningful — one unreachable host in a list of fifty, one file that could not be parsed. You report it and move on, and you leave the escalation decision to the caller. - **Terminating (`throw`)** when the function cannot sensibly continue — a mandatory parameter that fails validation, a missing dependency, an authentication failure that makes every subsequent call pointless. Continuing would only produce a cascade of secondary errors that obscure the real one. ## The classic bug ```powershell function Save-Report { param($Data) if (-not $Data) { Write-Error 'No data supplied' # reports... } $Data.Rows.Count # ...and then runs anyway } ``` The author expected `Write-Error` to act like `throw`. It does not: the function continues and fails again a line later with a confusing null-reference error that hides the real cause. If you report and want to stop, follow it with `return`; if the situation is genuinely unrecoverable, use `throw` in the first place. ## Related surfaces worth naming `Write-Warning` and `Write-Verbose` are *not* errors — they go to different streams, never set `$?`, and never populate `$Error`. Using `Write-Host` to announce a failure is worse still: it puts the message on the display where no caller can capture, filter or count it. And inside an advanced function, `$PSCmdlet.ThrowTerminatingError()` is the fully-featured version of `throw` — it emits an `ErrorRecord` you built yourself, with your own error ID and target object, rather than a wrapped string. ## What the caller sees Whichever you choose, everything the caller can inspect arrives as an `ErrorRecord`: `$_` inside their `catch`, or the entries in `$Error` and in an `-ErrorVariable`. Writing a good message, a real target object and a stable error ID is therefore not decoration — it is the interface your failure exposes.