Sometimes when something goes wrong in Windows PowerShell, it isn't a bad thing. That is, there are certain conditions that you can anticipate and potentially deal with, such as a missing file or a computer that can't be contacted over the network. In response, you might want to prompt the user for an action to take or just log the error so that you can try again later. Windows PowerShell makes this possible through a scheme called error trapping and handling.
First, You Need an Error
To trap and handle an error, you actually need one to occur. Technically, in PowerShell terminology, you need an exception to occur. That can actually be a little tricky to do, believe it or not. For example, try running the following command. It will fail, but pay attention to what happens:
Get-WmiObject Win32_BIOS -comp 'localhost','not-here'
First, you should see the Win32_BIOS instance from your local computer. Then, you should see an error message (unless you actually have a computer named not-here on your network). Think you've seen an exception? Wrong. In PowerShell, just because you've seen an error message doesn't mean an exception was created. You can't trap or handle an error message. You can only trap and handle exceptions.
What you just saw was an example of a non-terminating exception. That is, an exception really did happen, but it wasn't so bad that the cmdlet needed to stop executing. So the cmdlet basically held the exception deep inside, suppressing its feelings of failure, and continued trying to do what you'd asked. You can't help the cmdlet if it isn't going to be more open with its feelings. In other words, you can't trap and handle non-terminating exceptions. Many of the problems a cmdlet can run into will typically generate a non-terminating exception. That's because cmdlets don't want folks to start calling them crybabies, so if something moderately bad happens, they just shut up and keep going.
This cmdlet behavior is controlled by a built-in PowerShell variable named $ErrorActionPreference. You can view its contents by simply typing the variable's name at the command line:
$ErrorActionPreference
By default, it's set to Continue, which is what cmdlets do when they encounter a non-terminating error—they keep going. The cmdlets also display error messages by default, but you can shut them off by setting $ErrorActionPreference to SilentlyContinue. Try it:
$ErrorActionPreference = "SilentlyContinue"
Get-WmiObject Win32_BIOS -comp 'localhost','not-here'
This time, the failure occurred but not a word was said about it. Our cmdlet just bit its lip and kept on going, not so much as whimpering about the error. Now, this is where a lot of new PowerShell users go wrong, so I need you to picture me standing up on a table and screaming, "Do not set $ErrorActionPreference to SilentlyContinue just to make the error messages go away."
Error messages are, by and large, good things. They tell us what's broken. They're like the nerves in your fingertips that tell you the stove you're about to touch is very hot. People who have problems with those nerves often burn themselves. We usually want to see error messages. What we don't want to see are the error messages that we can anticipate and deal with on our own.