PowerShell errors are easy to suppress — but should you?

There is an old saying that if you ignore something long enough, it will eventually go away. Admittedly, this saying isn’t always the best advice in day-to-day life, but it does have its place when it comes to PowerShell. As someone who writes lots of PowerShell scripts, I have run into plenty of situations in which a script is completely derailed by an unexpected error. In some of these cases, it’s good that the error caused the script to stop — otherwise, the script would have caused damage. In other cases, however, it would have been perfectly acceptable for the script to ignore the error and go on.

Whether you want to ignore error messages or halt a script’s execution when an error occurs, PowerShell has plenty of options for dealing with errors. In this article, I want to show you some of the techniques that I like to use.

Before I begin

Before I get started, I want to quickly point out that even though it is really easy to suppress PowerShell errors, doing so isn’t always the best option (although it can be). If you recklessly tell PowerShell to ignore errors, it can cause your script to behave unpredictably. Suppressing error messages also makes troubleshooting a lot more difficult.

Error action

Probably the most common technique for dealing with errors is to append the ErrorAction switch to a cmdlet. The ErrorAction switch lets you tell PowerShell what to do if the cmdlet produces an error.

If your goal is to suppress an error message and make it seem as though nothing has happened, then the error action of choice is SilentlyContinue. You can see an example of how this error action works in the image below. Here I am using the Get-Process cmdlet followed by the letter X. Since there is no process named X, the command produces an error. That error goes away when I append the SilentlyContinue error action. The error still occurs, but PowerShell simply ignores it.

PowerShell errors and the excessive use of error action

A while back, I saw a script that someone had written in which they appended -ErrorAction SilentlyContinue to nearly every cmdlet. In that particular situation, the script’s author was new to PowerShell and was desperately trying to make the errors in a script go away.

It goes without saying that ErrorAction was never intended as a magical cure-all for buggy scripts. Even so, I can envision situations in which a script has been well written, but if an error does happen to occur, then that error needs to be hidden from the end-user. In a situation like this, however, there is a more efficient option than simply appending the ErrorAction switch to every cmdlet.

If you need a script to behave in a certain way (such as suppressing any errors that occur), then you might consider setting up some preference variables. Preference variables function as configuration settings for PowerShell. For example, you might use a preference variable to control the number of history items that PowerShell retains or to force PowerShell to ask “are you sure” before performing certain actions. Here is how you can use a preference variable to set the ErrorAction to SilentlyContinue for the entire session:

$ErrorActionPreference = ‘SilentlyContinue’

You can see an example of how this works in the image below. Notice that the last command shown in the image does not include an error action, but the error is suppressed any way because of the error action preference variable that has been declared.

Incidentally, there are plenty of other error actions that you can specify other than SilentlyContinue. I won’t go into all of them, but here are some of the more useful ones:

• Continue: PowerShell displays the error message, but the script continues to run.
• Stop: PowerShell displays the error message and stops running the script.
• Inquire: PowerShell displays the error message but asks if you want to continue.

There is one other reason you might want to use an error action preference variable instead of relying on the ErrorAction switch. As previously mentioned, the ErrorAction switch has to be used in conjunction with a PowerShell cmdlet. Earlier, for instance, I used the Get-Process cmdlet to demonstrate how the ErrorAction switch works.

The problem with this is that not everything that you do in PowerShell involves using a cmdlet. Simple mathematical operations can be performed without the aid of a cmdlet. Similarly, you can assign a variable without using a cmdlet. This means that you cannot append the ErrorAction switch to these types of operations. Even though you can’t append the ErrorAction switch, you can use an error action preference variable to suppress errors produced when no cmdlets are being used. Let me show you an example.

In the first line of the screen capture above, I entered 2/0, which tells PowerShell to divide two by zero. Since dividing by zero is a mathematical impossibility, PowerShell displays an error.

Next, I tried dividing by zero again, but this time I attached the ErrorAction switch. However, because the ErrorAction switch has to be appended to a cmdlet and no cmdlet is being used, the command produced an error saying that ErrorAction is not allowed.

The third command that I entered sets the error action preference variable to SilentlyContinue, and the fourth line attempts to divide two by zero once again. This time the error is suppressed. In other words, the error action preference variable can suppress errors in situations where the ErrorAction switch is not.

PowerShell errors: Let them be

It’s usually best to allow PowerShell to go ahead and display errors that might occur. After all, it’s important to know when something isn’t working right. If you need to suppress an error, you can use the ErrorAction switch to suppress an error for a single cmdlet or an ErrorAction preference variable to suppress errors globally.

Featured image: Shutterstock