Czy kiedykolwiek uruchomiłeś skrypt lub cmdlet PowerShell i stałeś w obliczu krzyczącej ściany tekstu – w kolorze czerwonym – jak ta pokazana poniżej?
błędy mogą stać się przytłaczające i mylące. A przede wszystkim błędy są często trudne do odczytania, co sprawia, że określenie, co i gdzie skrypt poszedł źle prawie niemożliwe.,
na szczęście masz kilka opcji w PowerShell, aby to poprawić poprzez obsługę błędów. Korzystając z obsługi błędów, błędy mogą być filtrowane i wyświetlane w taki sposób, że łatwiej jest je zrozumieć. Zrozumienie błędu ułatwia dodanie większej logiki do obsługi błędów.
w tym artykule dowiesz się o błędach w PowerShell i jak można je przechwycić, aby wykonać obsługę błędów za pomocą bloków Try Catch
(oraz bloków finally
).,
spis treści
zanim przejdziemy do obsługi błędów, najpierw omówmy kilka koncepcji dotyczących błędów w PowerShell. Zrozumienie błędów może prowadzić do lepszych strategii obsługi błędów.
zmienna Automatyczna $Error
w PowerShell istnieje wiele zmiennych automatycznych, a jedną z nich jest zmienna automatyczna$Error
. PowerShell używa zmiennej $Error
do przechowywania wszystkich błędów napotkanych w sesji., Zmienna $Error
jest tablicą błędów posortowanych według najnowszych.
po pierwszym otwarciu sesji PowerShell zmienna$Error
jest pusta. Możesz to sprawdzić, wywołując zmienną $Error
.
jak widać, $Error
zmienna zaczyna się od pustego., Ale po wygenerowaniu błędu błąd zostanie dodany i zapisany do zmiennej $Error
.
w poniższym przykładzie błąd jest generowany przez celowe uzyskanie nazwy usługi, która nie istnieje.
PS> Get-Service xyzPS> $ErrorPS> $Error.Count
jak widać z powyższego wyjścia, wygenerowany błąd został dodany do zmiennej $Error
.,
zmienna $Error zawiera zbiór błędów generowanych w sesji PowerShell. Do każdego błędu można uzyskać dostęp poprzez wywołanie jego pozycji tablicy. Ostatni błąd będzie zawsze przy indeksie 0.
na przykład najnowszy błąd można pobrać za pomocą
$Error
.
Właściwości obiektu $Error
ponieważ wszystko w PowerShell jest obiektem, zmienna$Error
jest obiektem, a obiekty mają właściwości., Po umieszczeniu zmiennej $Error
w cmdlecie Get-Member
powinieneś zobaczyć listę dostępnych właściwości.
$Error | Get-Member
aby określić powodem błędu jest wyświetlenie zawartości właściwości InvocationInfo
za pomocą poniższego polecenia.,
$Error.InvocationInfo
teraz, możesz zrobić to samo z innymi właściwościami i dowiedzieć się, jakie inne informacje można znaleźć!
błędy kończące
błędy kończące zatrzymują przepływ wykonania, gdy zostanie napotkany przez PowerShell vs błędy nie kończące. Istnieje kilka sposobów wystąpienia błędu zakończenia. Jednym z przykładów jest wywołanie cmdleta z parametrem, który nie istnieje.,
Jak widać na poniższym zrzucie ekranu, po uruchomieniu polecenia Get-Process notepad
polecenie jest poprawne, a szczegóły procesu notatnika są wyświetlane.
ale, gdy parametr, który nie istnieje, jest używany jak Get-Process notepad -handle 251
, cmdlet wyświetla błąd, że parametr handle
jest nieprawidłowy. Następnie cmdlet kończy działanie bez pokazywania szczegółów procesu notepad
.,
błędy niekończące są błędami które nie zatrzymują wykonania skryptu lub polecenia. Na przykład sprawdź poniższy kod. Ten kod pobiera listę nazw plików z listy plików.plik txt. Następnie skrypt przechodzi przez każdą nazwę pliku, odczytuje zawartość KAŻDEGO pliku i wyświetla ją na ekranie.
$file_list = Get-Content .\filelist.txtforeach ($file in $file_list) { Write-Output "Reading file $file" Get-Content $file}
$file_list = Get-Content .\filelist.txtforeach ($file in $file_list) { Write-Output "Reading file $file" Get-Content $file}
zawartość listy plików.,plik txt to nazwy plików pokazane na poniższej liście.
File_1.logFile_2.logFile_3.logFile_4.logFile_5.logFile_6.logFile_7.logFile_8.logFile_9.logFile_10.log
ale co jeśli Plik_6.dziennik nie istniał? Po uruchomieniu kodu można się spodziewać wystąpienia błędu, ponieważ skrypt nie może znaleźć pliku Formula_6.log. Zobaczysz podobny wynik pokazany poniżej.
jak widać na zrzucie ekranu wyniku powyżej, skrypt był w stanie odczytać pierwsze pięć plików na liście, ale gdy próbował odczytać plik formula_6.,txt, zwracany jest błąd. Następnie skrypt kontynuował odczytywanie reszty plików przed zakończeniem. Nie wygasła.
zmienna $ErrorActionPreference
do tej pory dowiedziałeś się o błędach kończących i nie kończących oraz o tym, jak różnią się one od siebie. Ale czy wiesz, że błąd nie kończący się może być traktowany jako błąd kończący?
PowerShell ma koncepcję zwaną zmiennymi preferencji. Zmienne te są używane do zmiany zachowania PowerShell na wiele różnych sposobów. Jedną z tych zmiennych jest $ErrorActionPreference
.,
zmienna$ErrorActionPreference
służy do zmiany sposobu, w jaki PowerShell traktuje nie kończące się błędy. Domyślnie wartość $ErrorActionPreference
jest ustawiona naContinue
. Zmiana wartości zmiennej $ErrorActionPreference
na STOP
wymusza traktowanie wszystkich błędów jako błędów kończących.
użyj poniższego kodu, aby zmienić wartość$ErrorActionPreference
.,
$ErrorActionPreference = "STOP"
aby dowiedzieć się więcej o innych ważnych wartościach zmiennej $ErrorActionPreference, odwiedź Stronę PowerShell ErrorActionPreference.
teraz wróć do przykładu użytego w sekcji niekończące się błędy w tym artykule. Skrypt może zostać zmodyfikowany tak, aby zawierał zmiany w $ErrorActionPreference
tak jak kod pokazany poniżej:
uruchomienie powyższego zmodyfikowanego kodu będzie zachowywać się inaczej niż wcześniej, gdy wartość $ErrorActionPreference
zostanie ustawiona na wartość domyślną Continue
.,
jak widać na zrzucie ekranu z powyższego wyniku skrypt był w stanie odczytać pierwsze pięć plików z listy, ale gdy próbował odczytać plik file_6.txt, zwracany jest błąd, ponieważ plik nie został znaleziony. Następnie skrypt zostanie zakończony, a reszta plików nie zostanie odczytana.,
wartość
$ErrorActionPreference
jest ważna tylko w bieżącej sesji PowerShell. Resetuje się do wartości domyślnej po rozpoczęciu nowej sesji PowerShell.
parametr Common ErrorAction
Jeśli wartość$ErrorActionPreference
jest zastosowana do sesji PowerShell, parametrErrorAction
ma zastosowanie do każdego cmdletu obsługującego wspólne parametry. ParametrErrorAction
przyjmuje te same wartości, co zmienna$ErrorActionPreference
.,
ErrorAction
wartość parametru ma pierwszeństwo przed wartością$ErrorActionPreference
.
wróćmy do tego samego kodu w poprzednim przykładzie. Jednak tym razem parametr ErrorAction
jest dodawany do linii Get-Content
.
Po uruchomieniu zmodyfikowanego kodu zobaczysz, że nawet jeśli $ErrorActionPreference
jest ustawione na Continue
, skrypt nadal jest zakończony po napotkaniu błędu., Skrypt zakończył działanie, ponieważ-ErrorAction
wartość parametru wGet-Content
jest ustawiona naSTOP
.
używając PowerShell spróbuj złapać bloki
w tym momencie dowiedziałeś się o błędach PowerShell i o tym, jak działają parametry $ErrorActionPreference
I ErrorAction
., Teraz nadszedł czas, aby dowiedzieć się o dobrych rzeczach – blokach PowerShell Try Catch Finally
.
PowerShelltry catch
bloki (i opcjonalnefinally block
) są sposobem na rzucenie sieci wokół kawałka kodu i wychwycenie błędów, które zwracają.
poniższy kod pokazuje składnię instrukcjiTry
.
try { <statement list>}catch *]{ <statement list>}finally { <statement list>}
blok Try
zawiera kod, który chcesz PowerShell „spróbować” i monitorować pod kątem błędów., Jeśli kod w bloku Try
napotka błąd, błąd jest dodawany do zmiennej $Error
, a następnie przekazywany do bloku Catch
.
BlokCatch
zawiera akcje do wykonania, gdy otrzyma błąd z blokuTry
. Może być wiele bloków Catch
w Try
.
BlokFinally
zawiera ten kod, który będzie na końcu instrukcjiTry
., Blok ten działa bez względu na to, czy błąd został niezliczony.
Przechwytywanie nieswoistych błędów (Catch-All)
prostaTry
instrukcja zawieraTry
ICatch
blok. Blok Finally
jest opcjonalny.
na przykład, aby złapać niespecyficzny wyjątek, parametr Catch
powinien być pusty. Poniższy przykładowy kod używa tego samego skryptu, który został użyty w sekcji zmiennej $ ErrorActionPreference, ale zmodyfikowany w celu użycia bloków Try Catch
.,
jak widać z poniższego kodu, tym razem deklaracja foreach
jest zamknięta wewnątrz bloku Try
. Następnie blok Catch
zawiera kod wyświetlający ciąg znaków An Error Occurred
jeśli wystąpił błąd. Kod w blokuFinally
usuwa zmienną$Error
.
powyższy kod, po uruchomieniu w PowerShell, da ci to wyjście pokazane poniżej.,
powyższe wyjście pokazuje, że skrypt napotkał błąd, uruchomił kod wewnątrzCatch
blok, a następnie zakończony.
obsługiwano błąd, który był punktem obsługi błędów. Wyświetlany błąd był jednak zbyt ogólny. Aby wyświetlić bardziej opisowy błąd, możesz uzyskać dostęp do właściwości Exception
błędu przekazanego przez blok Try
.,
poniższy kod jest modyfikowany, w szczególności kod wewnątrz bloku Catch
, aby wyświetlić komunikat wyjątku z bieżącego błędu przekazanego w potoku – $PSItem.Exception.Message
tym razem, gdy zmodyfikowany kod jest uruchomiony powyżej, wyświetlana wiadomość jest o wiele bardziej opisowa.,
Przechwytywanie określonych błędów
są czasy, gdy przechwytywanie wszystkich błędów nie jest to najodpowiedniejsze podejście. Być może chcesz, aby skrypt wykonał akcję zależną od rodzaju napotkanego błędu.
Jak określić typ błędu? SprawdzającTypeName
wartość właściwościException
ostatniego błędu., Na przykład, aby znaleźć typ błędu z poprzedniego przykładu, użyj polecenia:
$Error.Exception | Get-Member
wynik powyższego kodu będzie wyglądał jak zrzut ekranu poniżej. Jak widać, wyświetlana jest wartość TypeName
– System.Management.Automation.ItemNotFoundException
.
teraz, gdy znasz typ błędu, który musisz przechwycić, zmodyfikuj kod, aby go przechwycić., Jak widać ze zmodyfikowanego kodu poniżej, są teraz dwa bloki Catch
. PierwszyCatch
blok przechwytuje określony typ błędu (System.Management.Automation.ItemNotFoundException
). Natomiast drugi blokCatch
zawiera ogólny komunikat o błędzie catch-all.
poniższy zrzut ekranu pokazuje wyjście zmodyfikowanego kodu powyżej.,
podsumowanie
w tym artykule nauczyłeś się o błędach w PowerShell, jego właściwości i sposób określenia określonego typu błędu. Poznałeś również różnicę między tym, jak zmienna $ErrorActionPreference
a parametrem ErrorAction
wpływa na sposób, w jaki PowerShell traktuje błędy nie kończące się.,
nauczyłeś się również, jak używać bloków PowerShellTry Catch Finally
do obsługi błędów, czy to w przypadku konkretnych błędów, czy w podejściu catch-all.
przykłady przedstawione w tym artykule pokazują tylko podstawy działania blokówTry Catch Finally
. Wiedza, którą mam nadzieję, że zdobyłeś w tym artykule, powinna dać ci początkowe bloki, aby rozpocząć stosowanie obsługi błędów w swoich skryptach.,
dalsze czytanie
- O_try_catch_finally
- O_automatic_variables
- powrót do podstaw: pętla PowerShell foreach
- powrót do podstaw: zrozumienie obiektów PowerShell