Try and Catch PowerShell: Syntax, Examples, and Best Practices

try and catch powershell is PowerShell’s structured error-handling construct that intercepts terminating exceptions in a try block, routes them to a typed catch block, and optionally runs a finally block for resource cleanup. It is the primary mechanism for production-grade script resilience.

# Minimal structure
try {
    # Risky code here
}
catch {
    # Handles any terminating error
    Write-Host "Error caught: $_"
}

Syntax Reference

Tested on Windows Server 2022 with PowerShell 7.4, and Windows 10/11 with PowerShell 5.1.

# With specific error type and finally block
try {
    Get-Item "C:MissingFile.txt" -ErrorAction Stop
}
catch [System.IO.FileNotFoundException] {
    Write-Host "File not found."
}
catch {
    Write-Host "Other error: $($_.Exception.Message)"
}
finally {
    # Always executes — even on exception
    Write-Host "Cleanup complete."
}

# Using throw inside try
try {
    if (-not (Test-Path $path)) {
        throw "Path does not exist: $path"
    }
}
catch {
    Write-Error $_.Exception.Message
}

# Global trap alternative (less granular)
trap { Write-Host "Global trap caught: $_"; continue }
1/0  # Division by zero triggers trap

Rapid Reference Cheat Sheet

Advanced Implementation & Parameters

Terminating vs Non-Terminating Errors

PowerShell distinguishes two error categories. Terminating errors (e.g., throw, type mismatch, -ErrorAction Stop) are caught by try/catch. Non-terminating errors (e.g., Get-ChildItem on an inaccessible subpath) are written to the error stream but do not trigger a catch block unless you explicitly use -ErrorAction Stop or set $ErrorActionPreference = "Stop".

The $Error automatic variable stores all non-terminating errors as a stack. To inspect the most recent error outside of a catch block:

$Error[0].Exception.Message

Multiple Catch Blocks and Error Typing

You can specify multiple catch blocks for distinct exception types. Place derived classes before general classes; otherwise the first matching block catches all. PowerShell wraps every exception in System.Management.Automation.RuntimeException, so explicit type filters must be ordered correctly.

try {
    Get-Mailbox -Identity "nonexistent" -ErrorAction Stop
}
catch [Microsoft.Exchange.Management.Tasks.ManagementObjectNotFoundException] {
    Write-Host "Mailbox not found."
}
catch [System.UnauthorizedAccessException] {
    Write-Host "Access denied."
}
catch {
    Write-Host "Unexpected error: $($_.Exception.GetType().FullName)"
}

ErrorAction and $ErrorActionPreference

Cmdlets respect -ErrorAction at the statement level. The preference variable $ErrorActionPreference applies to the entire scope. Common values: Stop, Continue (default), SilentlyContinue, Ignore, Inquire. Setting SilentlyContinue or Ignore suppresses throw-generated errors.

Finally Block

The finally block executes regardless of whether an exception was thrown or caught. It is the correct place to close file handles, database connections, or release COM objects. The finally block runs before the script terminates.

Error Resolution & Troubleshooting

Common Code Smells and Fixes

Pattern — using boolean flag to indicate success:

try {
    Get-Mailbox "user" -ErrorAction Stop
    $success = $true
}
catch {
    $success = $false
}
if ($success) { Write-Host "Mailbox retrieved." }

This is a valid pattern for catch-and-continue workflows. The flag allows subsequent logic to proceed without nesting inside the try block.

Pattern — silent retry on transitory error:

$retries = 3
do {
    try {
        Get-Content "\serversharefile.txt" -ErrorAction Stop
        break
    }
    catch {
        $retries--
        Start-Sleep -Seconds 2
    }
} while ($retries -gt 0)

Production-Grade Implementation

In unattended automation and CI/CD pipelines (Azure DevOps, GitHub Actions with PowerShell tasks), unhandled errors fail jobs. Enforce strict error handling with -ErrorAction Stop on every cmdlet that can fail and encapsulate all business logic in try/catch/finally. To minimize latency in try and catch powershell execution, avoid using catch blocks for flow control on non-exceptional paths — prefer if/else with Test-Path or -ErrorAction SilentlyContinue with manual $? checks for expected states. Reserve catch for genuine exception handling.

Security and Least Privilege: Never log or expose $_.Exception.Message directly to end users without sanitization — internal paths, server names, and credentials may leak. Write errors to a secure log file and present a generic message to the console. Use Write-Error inside catch to propagate structured errors to the calling pipeline without exposing internals.

# Secure error handling pattern
$logPath = "C:securelogsscript.log"
try {
    Get-ADUser "jdoe" -ErrorAction Stop
}
catch {
    # Log full exception internally
    "$(Get-Date) ERROR: $($_.Exception.Message)" | Out-File $logPath -Append
    # Expose only a sanitized message to console
    Write-Warning "User retrieval failed. Administrator has been notified."
}

Performance consideration: If you expect a high volume of non-critical failures (e.g., network timeouts in a loop), consider -ErrorAction SilentlyContinue with selective $Error.RemoveAt(0) to avoid unbounded growth of the $Error stack. Use try/catch only for exceptions that genuinely require a different code path.