Prof. Powershell

Fanfare for the Common Parameter Part 2: Error

Part two of this how-to series will look at how to deal with error-related parameters in PowerShell.

• By Jeffery Hicks
• 06/25/2013

Last time we began a series of lessons on the common parameters you get with every cmdlet and advanced PowerShell function. If you want to get a jump, read the help topic About_CommonParameters. This week let's take a look at error-related parameters.

This is a common parameter you are most likely to use on a regular basis, especially when scripting. Without getting into a long side-discussion about PowerShell error handling, suffice it to say that instead of setting a scope specific setting for $ErrorActionPreference, you can set the preference at the cmdlet level with –ErrorAction parameter. You can use the same value you would use setting the preference variable, either by name or integer equivalent.

• SilentlyContinue (0)
• Stop (1)
• Continue (2) [this is the default behavior]
• Inquire (3)
• Ignore (4) [parameter value only]

Typically, we need to set the error action to stop when using a Try/Catch block.

Try {
get-wmiobject win32_computersystem -computer $name -ErrorAction stop
}
Catch {
Write-Warning "Failed to get results from $name"
Write-Warning $_.exception.message
}

The parameter also has an alias of –ea. You would write the Try command like this:

get-wmiobject win32_computersystem -computer $name -ea 1

Personally, I wouldn't do this in a script because it isn't clear what –ea means or the value 1. But if you are running a command from a prompt, by all means take advantage of the shortcuts.

In PowerShell 3, we have a new Ignore value as an error action preference. But be careful. Normally, when there is an exception, it is added to the builtin $Error variable, even if the error action preference is SilentlyContinue. Choosing Ignore suppresses the error message and the exception.

Speaking of $Error and exceptions, there is a related common parameter you might want to use, -ErrorVariable, which has an alias of -ev. With this parameter, you can define your own error variable.

PS C:\> get-service foobar -ev e

The exception will be stored in $Error AND my variable $e. If you would like to append to the variable, preface it with a + sign like this.

PS Scripts:\> get-service fooby -ev +e

One reason you might want to do this is to keep track of script errors without trying to process $Error.

$names = get-content c:\work\computers.txt

#clear the variable if it exists
if ($MyErr) { Clear-Variable MyErr }

foreach ($name in $names) {
Try {
get-wmiobject win32_computersystem -computer $name -ErrorAction Stop -ErrorVariable +MyErr
}
Catch {
Write-Warning "Failed to get results from $name"
Write-Warning $MyErr[-1].message
}
}

#export errors for analysis
$MyErr | Export-Clixml c:\Work\MyErr.xml

In this example any errors are appended to the MyErr variable. Because the object is an exception, I adjusted the code in my Write-Warning command to display the last entry, which should be the most current exception. Remember, exceptions get "caught" by the Catch block.  At the end of my command I export all of my errors to an XML file so I can look at them later.

While you are more likely, I think, to use these error-related common parameters, you can use them anywhere you can run a cmdlet or advanced function that uses cmdlet binding. In our next lesson we'll look at a common parameter for other pipelined output.