Chapter 24: Handling errors

Introduction

The chapter introduces two ways to retain PowerShell errors for later handling: the automatic $Error variable and the ErrorVariable common parameter.

• Automatic error history: Explain that $Error contains error objects from the current session, with the most recent at $Error[0], and that setting ErrorAction to Ignore prevents errors from being added to it.
  Why it matters: This gives you a way to find errors after they occur.
• ErrorVariable error collection: Describe using the ErrorVariable common parameter to retain errors for later use, such as logging. Explain that it holds only the most recent error unless its name is prefixed with a plus sign, and that the name is written without a dollar sign here.
  Why it matters: Keeping errors lets you use them later, for example when writing a log file.

Key terms: $Error, $Error[0], ErrorAction, Ignore, ErrorVariable, +

24.1 Understanding errors and exceptions

Explains why PowerShell often continues after an error and how to make a command stop so code can handle the problem.

• Nonterminating error behavior: Explain why a PowerShell command may report a problem with one item yet continue processing the others.
  Why it matters: An error message does not necessarily mean the command stopped.
• Error action controls: Describe how $ErrorActionPreference and the per-command -ErrorAction parameter control responses to nonterminating errors.
  Why it matters: A per-command setting lets you change error behavior only where you need to.
• Stop action for exception handling: Explain why a command whose problem your code must handle usually needs -ErrorAction Stop.
  Why it matters: Without Stop, code intended to handle a command’s failure may never get an exception to handle.

Key terms: nonterminating error, Continue, $ErrorActionPreference, -ErrorAction, Stop, -EA Stop, exception

24.2 Bad handling

This section warns that suppressing errors too broadly—or without considering what else might fail—can hide problems that a script needs to reveal.

• Global versus command-level suppression: Explain why globally suppressing errors in a script or function is usually a bad practice, and describe the narrower alternative for an expected error.
  Why it matters: Keeping other errors visible makes unexpected failures easier to find.
• Hidden failures after suppression: Explain how even command-level error suppression can conceal a failure that matters.
  Why it matters: An error message you hide may be the clue that explains why the script did not work.

Key terms: preference variable, -EA SilentlyContinue, Remove-Item, permission

24.3 Two reasons for exception handling

This section distinguishes handling exceptions to record problems in unattended tools from handling anticipated failures while a command runs.

• Two reasons for exception handling: Distinguish between handling exceptions to preserve diagnostic evidence when a tool runs out of view and handling an anticipated problem so the code can actively deal with it.
  Why it matters: The reason you handle an exception determines whether you are preserving evidence of a failure or responding to an expected one.

Key terms: exceptions, $ErrorActionPreference, Stop, error-handling construct

24.4 Handling exceptions

Shows how to handle failures when a script connects to remote computers, including whether to stop, continue, or report errors.

• Terminating exceptions and Try Catch: Explain why the potentially failing New-PSSession command must generate a terminating exception and what happens when that exception occurs inside a Try block.
  Why it matters: This lets a script respond to a failed connection rather than continuing through code that assumes it succeeded.
• Multiple computer failure choices: Distinguish the section’s two ways to handle failures across multiple computers, and explain how the choice depends on whether partial success is acceptable.
  Why it matters: Choosing how to continue determines whether successful connections proceed and whether failures remain available to investigate.
• Warnings from the Catch block: Describe how the Catch block informs the user about a failure and how the user can suppress that warning.
  Why it matters: A warning makes a handled failure visible without requiring the script to hide it.

Key terms: New-PSSession, terminating exception, ErrorAction, Stop, Try/Catch, foreach, ErrorVariable, computername, Catch block, warning

24.5 Handling exceptions for noncommands

Explains how to catch exceptions from operations without -ErrorAction and identifies a last-resort way to make an exception catchable.

• Noncommand exception behavior: Explain why a .NET Framework method without -ErrorAction can usually be run directly in a Try block, and contrast its errors with nonterminating errors from PowerShell commands.
  Why it matters: It tells you when a Try block is usually enough, even though the operation has no -ErrorAction parameter.
• Last resort preference change: Describe the last-resort approach of temporarily modifying $ErrorActionPreference for the one operation whose exception you want to catch.
  Why it matters: It gives you a fallback without treating a preference change as the normal way to handle every exception.

Key terms: .NET Framework method, -ErrorAction, Try block, terminating exceptions, nonterminating exception, $ErrorActionPreference, error handling of last resort

24.6 Going further with exception handling

This section extends Try/Catch handling with exception-specific Catch blocks and Finally, and advises against using Trap in new code.

• Exception-specific Catch blocks: Explain how multiple Catch blocks can follow one Try block to handle different exception types differently, and what information is needed to specify those types.
  Why it matters: Different failures can call for different responses instead of one response to every error.
• Finally block behavior: Describe when an optional Finally block runs in relation to Try and Catch.
  Why it matters: Finally provides a place for code that must run whether the attempted operation succeeds or fails.
• Trap versus Try/Catch: Explain why the section recommends Try/Catch rather than Trap for newly written exception-handling code.
  Why it matters: This helps you choose the recommended construct when writing new error-handling code.

Key terms: Catch blocks, .NET Framework type name, exception, Finally block, Try, Catch, Trap, deprecated, backward compatibility, Try/Catch

24.7 Lab