Powershell suppress error output

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.

Freepik / Designed by Gstudioimagen

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:

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.

Источник

Suppressing PowerShell Errors

Whether we want to ignore error messages or terminate a script’s execution when an error occurs, Windows PowerShell has plenty of options for dealing with errors. This article will discuss multiple techniques in handling and suppressing errors.

Introduction to Error Action in PowerShell

Even though it is effortless to suppress Windows PowerShell errors, doing so isn’t always the best option (although it can be). If we carelessly tell PowerShell to hide errors, it can cause our script to behave unpredictably.

Suppressing error messages also makes troubleshooting and information gathering a lot more complicated. So tread lightly and be careful about using the following snippets that you will see in this article.

Use the -ErrorAction Parameter in PowerShell

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

In the command above, we are querying for a service that doesn’t exist. Usually, PowerShell will throw an error if the service doesn’t exist.

Since we use the -ErrorAction parameter, the script will continue as expected, like it doesn’t have an error.

Setting Error Action Preferences in PowerShell

If we need a script to behave in a certain way (such as suppressing errors), we might consider setting up some preference variables. Preference variables act as configuration settings for PowerShell.

We might use a preference variable to control the number of history items that PowerShell retains or force PowerShell to ask the user before performing specific actions.

For example, here is how you can use a preference variable to set the -ErrorAction parameter to SilentlyContinue for the entire session.

There are many other error actions that we can specify for the ErrorAction switch parameter.

• Continue : PowerShell will display the error message, but the script will continue to run.
• Ignore : PowerShell does not produce any error message, writes any error output on the host, and continues execution.
• Stop : PowerShell will display the error message and stop running the script.
• Inquire : PowerShell displays the error message but will ask for confirmation first if the user wants to continue.
• SilentlyContinue : PowerShell silently continues with code execution if the code does not work or has non-terminating errors.
• Suspend : PowerShell suspends the workflow of the script.

As previously mentioned, the -ErrorAction switch has to be used in conjunction with a PowerShell cmdlet. For instance, we used the Get-Process cmdlet to demonstrate how the ErrorAction switch works.

Marion specializes in anything Microsoft-related and always tries to work and apply code in an IT infrastructure.

Источник

Discarding Output

If you’d like to discard unwanted output from commands, understanding and managing output streams is key. And if all else fails, you can always temporarily disable Out-Default.

When you write PowerShell scripts, you typically want to control the information sent back to the user. So when your script uses commands, you don’t necessarily want these commands to emit their output directly to the user.

Understanding Streams

In a perfect world, controlling and discarding command output is simple because commands typically use PowerShell streams to emit information, and you can redirect streams and assign them to variables or $null .

Suppressing Output Stream

For example, if all you want is creating a new folder, you can direct the output stream to $null and discard the information sent back by New-Item :

Showing Or Hiding Streams

In fact, there is a series of preference variables that allow you to selectively show or hide various streams:

Simply set a stream to Continue to make it visible, and to SilentlyContinue to hide it:

Each stream corresponds with Write-cmdlets and a stream number:

There are two streams that are not controlled by preference variables and are always visible: Output and Host.

The Output stream is the one that is piped to downstream cmdlets and assigned to variables. The Host stream shares the stream id 6 with the Information stream and can be silenced by redirecting stream 6.

Redirecting Streams

By default, only the Output stream is assigned to variables. All other streams either are emitted directly to the console, or are hidden (controlled by your preference variables).

To include the information from other streams in your variables, use redirection: take the stream id to redirect the stream to the output stream (&1).

This line redirects errors and warnings to the output stream and assigns them to a variable:

After you run it, $all contains the results plus all errors and warnings.

Special Case: Write-Host

Write-Host did not play by the rules and bypassed the stream system up until PowerShell 5 (thanks Justin for pointing out). Ever since, Write-Host is sharing the Information stream, and that’s important to know. Because of this, it is ok to use Write-Host again:

• Write-Host : use this cmdlet for messages that a user should always see. Even though Write-Host is using the Information stream, it is not affected by any preference variable such as $InformationPreference , and always set to Continue.
• Write-Information : use this cmdlet for messages that a user should not see by default ( $InformationPreference defaults to SilentlyContinue) but that a user might choose to turn on.

Here is a proof of concept illustrating how you can hide messages emitted by Write-Host :

By redirecting stream 6 to null, all outputs from Write-Host and Write-Information are discarded. You can append 6>$null to any command or script call.

While at it, there are two ways of discarding streams:

The first line redirects to $null which really is the same as redirecting to an empty string because the redirection operator takes only strings, so $null is converted to a string:

This is a special use case of the redirection operator. Typically, it expects a filename and writes the stream to this file. When you specify an empty string, the stream is nuked.

In contrast, the second line redirects the stream to the output stream (id #1) so the stream is merged into the output and can be assigned to variables, including the special variable $null .

This is a fundamentally different approach. The first line enables you to selectively discard streams that you want to hide. The second line enables you to assign or discard the entire mixture of output stream and any other stream you merged into the output stream.

Why Some Commands Are Ugly

Occasionally, you may stumble across commands that don’t play by the rules and write output that simply can’t be suppressed.

For example, Get-WindowsUpdateLog is a command on Windows 10 that extracts update information from .etl files and generates a log file for you:

When you run this command, it emits a ton of information, and there doesn’t seem to be a way to hide or discard this information:

Even if you redirect all streams (including stream 6) to the output stream and send everything to $null , the messages still show in the console.

Writing Directly To Host

This problem occurs whenever commands write directly to the console and bypass the stream mechanism. Here is a line of code that illustrates the problem:

Silencing All Output

To silence direct console output and discard all output, you can temporarily disable the internal PowerShell command Out-Default . This command is used privately to write directly to the console.

While you really can’t disable the command (it is hard-coded to PowerShell), you can replace it with your own functions, effectively overwriting it. So here is some example code that runs Get-WindowsUpdateLog without showing all the status messages:

As long as Out-Default is replaced by your own empty function, PowerShell emits no output whatsoever. This applies to scripts as well as interactive commands you may invoke. So make sure you remove your function Out-Default once you are ready to see output again.

This Out-Default trick isn’t as edge-casy as you may think. When you browse user groups you’ll discover plenty of threads that deal with this issue.

PowerShell users have resorted to all kinds of creative and complex workarounds to discard direct console output, i.e. running code as a job or in another PowerShell instance with a hidden window.

You know now: that’s a bit of overkill. Simply shadow Out-Default for as long as you want to silence PowerShell.

/
This Article is licensed under a Attribution-NoDerivatives 4.0 International license.
All Code samples are licensed under a Attribution 4.0 International license. Use, share, and experiment freely.

Источник

1. Introduction to Error Action in PowerShell
2. Use the -ErrorAction Parameter in PowerShell
3. Setting Error Action Preferences in PowerShell

Whether we want to ignore error messages or terminate a script’s execution when an error occurs, Windows PowerShell has plenty of options for dealing with errors. This article will discuss multiple techniques in handling and suppressing errors.

Introduction to Error Action in PowerShell

Even though it is effortless to suppress Windows PowerShell errors, doing so isn’t always the best option (although it can be). If we carelessly tell PowerShell to hide errors, it can cause our script to behave unpredictably.

Suppressing error messages also makes troubleshooting and information gathering a lot more complicated. So tread lightly and be careful about using the following snippets that you will see in this article.

Use the -ErrorAction Parameter in PowerShell

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

Command:

Get-Service 'svc_not_existing' -ErrorAction SilentlyContinue

In the command above, we are querying for a service that doesn’t exist. Usually, PowerShell will throw an error if the service doesn’t exist.

Since we use the -ErrorAction parameter, the script will continue as expected, like it doesn’t have an error.

Setting Error Action Preferences in PowerShell

If we need a script to behave in a certain way (such as suppressing errors), we might consider setting up some preference variables. Preference variables act as configuration settings for PowerShell.

We might use a preference variable to control the number of history items that PowerShell retains or force PowerShell to ask the user before performing specific actions.

For example, here is how you can use a preference variable to set the -ErrorAction parameter to SilentlyContinue for the entire session.

Command:

$ErrorActionPreference = 'SilentlyContinue'

There are many other error actions that we can specify for the ErrorAction switch parameter.

• Continue: PowerShell will display the error message, but the script will continue to run.
• Ignore: PowerShell does not produce any error message, writes any error output on the host, and continues execution.
• Stop: PowerShell will display the error message and stop running the script.
• Inquire: PowerShell displays the error message but will ask for confirmation first if the user wants to continue.
• SilentlyContinue: PowerShell silently continues with code execution if the code does not work or has non-terminating errors.
• Suspend: PowerShell suspends the workflow of the script.

As previously mentioned, the -ErrorAction switch has to be used in conjunction with a PowerShell cmdlet. For instance, we used the Get-Process cmdlet to demonstrate how the ErrorAction switch works.

When you write PowerShell scripts, you typically want to control the information sent back to the user. So when your script uses commands, you don’t necessarily want these commands to emit their output directly to the user.

Understanding Streams

In a perfect world, controlling and discarding command output is simple because commands typically use PowerShell streams to emit information, and you can redirect streams and assign them to variables or $null.

Suppressing Output Stream

For example, if all you want is creating a new folder, you can direct the output stream to $null and discard the information sent back by New-Item:

# create a new folder and discard returned information
$null = New-Item -Path 'c:newfolder' -ItemType Directory

Showing Or Hiding Streams

In fact, there is a series of preference variables that allow you to selectively show or hide various streams:

Get-Variable -Name *preference -Exclude *confirm*,*whatif*,*progress*   

Simply set a stream to Continue to make it visible, and to SilentlyContinue to hide it:

Name                  Value
----                  -----
DebugPreference       SilentlyContinue
ErrorActionPreference Continue
InformationPreference SilentlyContinue
VerbosePreference     SilentlyContinue
WarningPreference     Continue

Each stream corresponds with Write-cmdlets and a stream number:

There are two streams that are not controlled by preference variables and are always visible: Output and Host.

The Output stream is the one that is piped to downstream cmdlets and assigned to variables. The Host stream shares the stream id 6 with the Information stream and can be silenced by redirecting stream 6.

Redirecting Streams

By default, only the Output stream is assigned to variables. All other streams either are emitted directly to the console, or are hidden (controlled by your preference variables).

To include the information from other streams in your variables, use redirection: take the stream id to redirect the stream to the output stream (&1).

This line redirects errors and warnings to the output stream and assigns them to a variable:

# include errors and warnings in variable results:
$all = Get-Process -FileVersionInfo 2>&1 3>&1

After you run it, $all contains the results plus all errors and warnings.

Special Case: Write-Host

Write-Host did not play by the rules and bypassed the stream system up until PowerShell 5 (thanks Justin for pointing out). Ever since, Write-Host is sharing the Information stream, and that’s important to know. Because of this, it is ok to use Write-Host again:

• Write-Host: use this cmdlet for messages that a user should always see. Even though Write-Host is using the Information stream, it is not affected by any preference variable such as $InformationPreference, and always set to Continue.
• Write-Information: use this cmdlet for messages that a user should not see by default ($InformationPreference defaults to SilentlyContinue) but that a user might choose to turn on.

Here is a proof of concept illustrating how you can hide messages emitted by Write-Host:

& {
Write-Warning "A Warning"
"Regular Output"
Write-Host "This will dissappear!"
} 6>$null

By redirecting stream 6 to null, all outputs from Write-Host and Write-Information are discarded. You can append 6>$null to any command or script call.

While at it, there are two ways of discarding streams:

# two ways of discarding streams:
Write-Warning "A Warning" 3>$null
$null = Write-Warning "A Warning" 3>&1

The first line redirects to $null which really is the same as redirecting to an empty string because the redirection operator takes only strings, so $null is converted to a string:

Write-Warning "A Warning" 3>''

This is a special use case of the redirection operator. Typically, it expects a filename and writes the stream to this file. When you specify an empty string, the stream is nuked.

In contrast, the second line redirects the stream to the output stream (id #1) so the stream is merged into the output and can be assigned to variables, including the special variable $null.

This is a fundamentally different approach. The first line enables you to selectively discard streams that you want to hide. The second line enables you to assign or discard the entire mixture of output stream and any other stream you merged into the output stream.

Why Some Commands Are Ugly

Occasionally, you may stumble across commands that don’t play by the rules and write output that simply can’t be suppressed.

For example, Get-WindowsUpdateLog is a command on Windows 10 that extracts update information from .etl files and generates a log file for you:

When you run this command, it emits a ton of information, and there doesn’t seem to be a way to hide or discard this information:

# redirecting streams won't suppress the output
$null = Get-WindowsUpdateLog *>&1

Even if you redirect all streams (including stream 6) to the output stream and send everything to $null, the messages still show in the console.

Writing Directly To Host

This problem occurs whenever commands write directly to the console and bypass the stream mechanism. Here is a line of code that illustrates the problem:

# cannot be silenced:
& { [Console]::WriteLine("Hello") } *>$null

Silencing All Output

To silence direct console output and discard all output, you can temporarily disable the internal PowerShell command Out-Default. This command is used privately to write directly to the console.

Read more about Out-Default if you like.

While you really can’t disable the command (it is hard-coded to PowerShell), you can replace it with your own functions, effectively overwriting it. So here is some example code that runs Get-WindowsUpdateLog without showing all the status messages:

# temporarily overwrite Out-Default
function Out-Default {}

# run your code (guaranteed no output)
Get-WindowsUpdateLog

# test any other direct console write
[Console]::WriteLine("Hello")

# restore Out-Default
Remove-Item -Path function:Out-Default

As long as Out-Default is replaced by your own empty function, PowerShell emits no output whatsoever. This applies to scripts as well as interactive commands you may invoke. So make sure you remove your function Out-Default once you are ready to see output again.

This Out-Default trick isn’t as edge-casy as you may think. When you browse user groups you’ll discover plenty of threads that deal with this issue.

PowerShell users have resorted to all kinds of creative and complex workarounds to discard direct console output, i.e. running code as a job or in another PowerShell instance with a hidden window.

You know now: that’s a bit of overkill. Simply shadow Out-Default for as long as you want to silence PowerShell.