You need to understand how PowerShell handles errors and exceptions if you wish to create a script that behaves as you expect. It's a fact of life that on occasions your PowerShell scripts will throw errors.

No one writes perfect code or can account for the slew of environmental changes that may be going on to write a PowerShell script that executes correctly 100% of the time.

The first thing you'll need to realize when working with errors in PowerShell is that there's not just one kind of "error," there are two: terminating and non-terminating errors. You will undoubtedly come across both.

Non-terminating errors ^

Non-terminating errors are still "errors" in PowerShell but not quite as severe as terminating ones. Non-terminating errors aren't as serious because they do not halt script execution. Moreover, you can silence them, unlike terminating errors. You can create non-terminating errors with the Write-Error cmdlet. This cmdlet writes text to the error stream.

Write Error

Write Error

You can also manipulate non-terminating errors with the common ErrorAction and ErrorVariable parameters on all cmdlets and advanced functions. For example, if you've created an advanced function that contains a Write-Error reference, you can temporarily silence this as shown below.

Write Error output

Write Error output

I can silence this error with the built-in ErrorAction parameter and choose to SilentlyContinue as well.

You see when executing the above code, it will return nothing.

Terminating errors ^

Terminating errors are those that halt script execution. These errors are meant to be more serious than non-terminating errors. The most common way to create a terminating error is to use the throw command. The throw command "throws" an exception, which is essentially the same thing as a terminating error. For example, the below code will not return anything. You might expect that it would return "the string variable did not equal foo" because I did not include an else condition. However, it does not, because throw halts execution.

Terminating error

Terminating error

Unlike with non-terminating errors, the ErrorAction or ErrorVariable parameters cannot handle terminating errors. Only try/catch blocks can handle them. You can use this pair of blocks together to form a net of sorts around a piece of code. When a try block throws a terminating error, it will immediately halt execution of any further code inside of that try block and begin execution of the code inside of the catch block. The example below shows this behavior.

When run, the code returns the string "we ended up in the catch block." Without try/catch blocks, the code will simply write out a terminating error (exception) to the host as the first example shows. Here, we did not see any red error text but just the "we ended up in the catch block" string. This is how the code handles terminating errors.

Turning non-terminating errors into terminating errors ^

Sometimes you have no control over which errors are terminating vs. non-terminating. And you may want to ensure that when a script runs, it always stops for every error regardless of the type. To consider all errors as terminating errors, you can manipulate the $ErrorActionPreference automatic variable. This variable controls what happens when a non-terminating error occurs. The default setting for this variable is Continue. However, if you want to ensure every non-terminating error halts script execution just like a terminating error, you can change this to Stop as the example below shows.

By executing the above code, you'll see that it returns both the error and the output. This is because Write-Error returns a non-terminating error or sends a string to the error stream. However, when setting $ErrorActionPreference to Stop, you'll see that the code never returns "we are past the error here" because it halts script execution.

Wrap-up ^

Understanding how errors occur and how to invoke them at appropriate times is an important skill to master in PowerShell. Proper error handling can make the difference between a script that blows up and a well-structured one that is much more robust.

Join the 4sysops PowerShell group!

Your question was not answered? Ask in the forum!


Users who have LIKED this post:

  • avatar
1 Comment
  1. Rajaganesh Ramachandran 3 years ago

    Great to know, Thanks for the post.


Leave a reply

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2020


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account