Posts
Day 22 - Trapping and Handling Errors
I can lie. I skipped ahead in the book
when I ran into a problem at work and went through this chapter once already.
It prompted me to go another route with my thinking and to re-write the script
that I was writing to gather some info to include error handling. Ill get into
that a little more later on.
PowerShell doesn’t handle
non-terminating errors directly, so in order to make error handling work you
need to turn that error into an exception, or as Don puts it turn a
non-terminating error into a terminating error, and force the shell do what you
tell it to do.
The first thing we cover in the
chapter is PowerShells default error-handling variable. $ErrorActionPreference. By default this is set to continue when you
start the shell. You can specify the $ErrorActionPreference
for the entire script by setting this variable at the top of the script. The
settings for this variable are
SilentlyContinue
- Just keep going and don’t display an error message for non-terminating errors
Continue
- Display the error message but keep going anyway
Inquire
- Ask what you want to do at an interactive prompt
Stop
- Stop executing and throw an exception
Just a side note here: Regardless of
the setting of this variable in a script if a terminating error occurs an
exception is thrown and the script will stop.
Another way of handling errors on a
slightly more granular basis is by utilizing the -ErrorAction parameter that is available on almost all cmdlets that
are built into PowerShell.
Get-WmiObject Win32_Service -computer
localhost,notonline -erroraction 'silentlycontinue'
The preceding command will query WMI's
Win32 service namespace for the two listed PC's and unless you have a computer
named notonline will cause an error, only it will not display because we have
specified to silently continue. This method is especially useful in the
pipeline to display errors associated with individual objects and allowing the
script to continue.
The first actual way of error handling
in a script that we cover in this chapter is a Trap construct. Don says this is
the more complicated of the two error handling methods in the chapter mainly
due to the traps use of scopes. I would agree with that. Basically a trap is a
way to catch errors in a script, but it must be specified in the script before
an error can occur but it must be in the same scope or the parent scope. I do
not fully understand this yet and need to look into it further so for more info
please read the available documentation (help
about_trap).
The second method is the easier to
read and understand Try construct. With a Try construct there are three parts
(not all have to be used). The first is
TRY, and holds the original command you want to perform. The second part is
CATCH, and is what is executed if an
exception is thrown by the try portion. This can be used to log the error
information to a text file, execute another command to repair an issue, or any
other number of things. The last piece is FINALLY,
and executes on all objects passing through the Try construct regardless of
error. This portion is option. Here is the book example:
Function
Get-Stuff {
Begin {
del
c:\errors.txt -ea slientlycontinue
}
Process {
Try
{
Get-WMIobject Win32_bios -computer $_ -ea
Stop
}
Catch {
$_ | Out-File C:\Errors.txt -append
}
}
}
'Localhost','NotOnLine','Server-R2'
| Get-Stuff
As I stated before I skipped ahead for error
handling on a script I was trying to make for work and this is the method I
chose. I will be posting that up for my final script but would like to go over
it a little more before I do and document it. Maybe now that I know how, ill
put it up as a module so if anyone else wants to use it they can. Until
tomorrow have a great day.
No comments:
Post a Comment