Adam the Automator (Polski)

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?

przykład błędów w PowerShell

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.

zmienna $Error jest pusta

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
błąd jest dodawany do zmiennej $Error

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
Właściwości obiektu $Error

aby określić powodem błędu jest wyświetlenie zawartości właściwości InvocationInfo za pomocą poniższego polecenia.,

$Error.InvocationInfo
właściwość 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.

szczegóły procesu notatnika

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łąd jest wyrzucany, ponieważ parametr jest nieprawidłowy

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}

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.

przykład błędu bez zakończenia

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ść $ErrorActionPreferencejest ustawiona naContinue. Zmiana wartości zmiennej $ErrorActionPreference na STOPwymusza 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ść $ErrorActionPreferencezostanie ustawiona na wartość domyślną Continue.,

wymuszanie błędu zakończenia przy użyciu zmiennej $ErrorActionPreference

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ść$ErrorActionPreferencejest 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.

wymuszanie błędu zakończenia przy użyciu ErrorAction parametr

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 foreachjest 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.,

skrypt zakończony, gdy wystąpił błąd

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.,

skrypt zakończony opisowym Komunikatem o błędzie

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ść TypeNameSystem.Management.Automation.ItemNotFoundException.

uzyskanie wartości nazwy błędu

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.,

skrypt zakończony określonym komunikatem o błędzie

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

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *