HOWTO · PowerShell
How to Handle Errors Using Try-Catch Block in PowerShell
This article will discuss error action preferences in PowerShell and how we can intercept them to perform error handling using the PowerShell Try Catch and Finally blocks.
On this page
In PowerShell, try and catch handle terminating errors. Many cmdlets report errors as non-terminating, so add -ErrorAction Stop when an operation’s failure should reach a catch block. $ErrorActionPreference sets the default handling for non-terminating errors in its scope, while -ErrorAction sets behavior for one command.
the $ErrorActionPreference Variable in PowerShell
$ErrorActionPreference controls how PowerShell responds to non-terminating errors in its scope. Its default value is Continue: PowerShell reports the error and proceeds with the next statement. Setting it to Stop promotes non-terminating errors to terminating errors, so they can interrupt the current flow and be handled by a surrounding catch. After a catch handles an error, execution follows the surrounding control flow; an error does not automatically end the entire script.
Use a scoped change when only part of a script needs this behavior. Save the old value and restore it in a finally block if later commands should use the previous setting. This preference applies to commands that honor PowerShell’s error-action preferences, and it does not replace explicit handling for every kind of failure.
the ErrorAction Common Parameter in PowerShell
-ErrorAction is a common parameter supported by many cmdlets and functions. Its value applies to that command and takes precedence over $ErrorActionPreference for that invocation. For example, Get-Content $path -ErrorAction Stop makes a non-terminating read error terminating for that command. A surrounding catch can then handle it. The parameter changes how the command’s error is handled; recovery logic belongs in the surrounding script.
Values include Continue and Stop, along with actions such as SilentlyContinue, Ignore, Inquire, and Suspend where supported. Prefer -ErrorAction Stop on the operation whose failure should be caught instead of changing a wider scope. Commands can also produce terminating errors independently of this setting.
Use PowerShell try-catch Block
Put statements that may fail in try. A terminating error transfers control to a matching catch; an untyped catch handles any terminating error, while a typed form such as catch [System.IO.IOException] handles errors of that type. Place specific catches before a general catch. $Error is PowerShell’s automatic error-history collection, not a variable that represents only the current failure. Inside a catch block, $_ (also available as $PSItem) describes the current error record; its Exception or FullyQualifiedErrorId properties can help with diagnostics.
A finally block is optional and runs as control leaves the try statement, whether it completed normally or an error was handled. Use it for cleanup, such as disposing a resource opened before the operation. A catch block can recover, log, or rethrow an error; catching it does not by itself decide whether the surrounding script should continue its remaining work.
The following runnable example follows the successful path and prints a status line before its cleanup line. The code has no external file dependency.
try {
$reportName = "daily-report.txt"
Write-Output "Prepared $reportName"
}
finally {
Write-Output "Finished report step"
}
Prepared daily-report.txt
Finished report step
For a cmdlet whose non-terminating error should be caught, add -ErrorAction Stop to that cmdlet inside try. Keep paths and other inputs explicit in production scripts, then choose whether to log, retry, recover, or rethrow based on the operation. The sample demonstrates the successful path; adapt the same control-flow structure around the command whose failure you need to handle.