catchAllTheErrors-615x461obsługa błędu może przyprawić nieco problemu, dla tego kilka zebranych tips’n’tricks, które mogą się przydać.

try/catch nie działa!

czasem nie działa. a to dla tego, że klauza catch zostanie wykonana dla błędów ‚terminujących’. większość błędów natomiast jest ‚zwykłymi’ błędami, nieterminującymi. zachowanie można zmienić albo zmieniając standardowe zachowanie poprzez globalnie ustawienie zmiennej

co spowoduje nadpisanie wartości ustawionych dla commandletu.

można też po prostu dodać parametr ‚-ea’ dla konkretnego wywołania. przykład. to nie zadziała zgodnie z oczekiwaniami:

napis ‚tu nie działa’ nigdy się nie pojawi. poprawiona wersja:

zapytanie reqrsywne

problem z takim wymuszeniem jest w przypadq zapytań reqrsywnych. scenariusz: chciałbym wyszukać wszystkie katalogi, do których nie mam dostępu. robię reqrsywne przejście po katalogach i ustawiam błąd jako terminujący:

niby działa… ale, błąd jest terminujący. co oznacza, że po pierwszym wystąpieniu zakończy działanie wykonania. zobaczymy tylko pierwszy katalog, do którego nie mamy dostępu.

należy skorzystać z innej metody – przekazania błędów do zmiennej. uzysqje się to poprzez parametr ‚ErrorValue’ [alias ‚ev’]. wada jest taka, że zmienna zwracana jest po zakończeniu działania. tutaj już nie ma try/catch!

oczywiście jeśli nie chce się oglądać błędów z przebiegu, to można sobie dodać ‚-ea SilentlyContinue’ .

szczegóły błędu

na ekranie nadal będzie śmietnik. fajnie byłoby złapać tylko nazwy – i np. dla nich coś wykonać. dla tego warto zapoznać się z obiektem błędu:

teraz widać co mamy do dyspozycji. wyjątkowo ciekawe do obsługi będą ‚FullyQualifiedErrorId’ pozwalający na zdefiniowanie logiki zależnie od rodzaju błędu, oraz ‚TargetObject’ gdzie powinna znaleźć się informacja o obiekcie, który wygenerował błąd. proponuję przetestować, bo tak najlepiej się uczyć:

nie wszystko jest błędem

i na koniec – nie wszystko co my uważamy za błąd, jest błędem. nie mam teraz przygotowanego przykładu, niemniej zdarzało mi się, że commandlet zwracał null lub informował o niepowodzeniu – co było jak najbardziej prawidłowym zachowaniem a nie błędem per se. w takim przypadq trzeba sobie obsłużyć błąd zwykłym if’em bo try/catch tego nie znajdzie.

eN.