Obsługa błędów w PowerShell opiera się na blokach try-catch oraz parametrze ErrorAction wymuszającym błąd terminujący.
Różnica między błędem nieterminującym a terminującym
PowerShell rozróżnia błędy nieterminujące i terminujące. Błąd nieterminujący sygnalizuje problem, ale domyślnie nie przerywa wykonywania bieżącego polecenia ani całego skryptu. Taki sposób działania występuje między innymi wtedy, gdy polecenie nie może odczytać pliku, znaleźć ścieżki albo uzyskać dostępu do wskazanego zasobu. Informacja o błędzie trafia do strumienia błędów, a wykonanie może przejść do następnej instrukcji. Samo umieszczenie polecenia w bloku try nie gwarantuje więc przechwycenia każdego problemu przez catch.
Blok catch reaguje na błąd terminujący. Aby wymusić taki sposób obsługi dla polecenia, stosuje się parametr wspólny -ErrorAction Stop, na przykład Get-Content -LiteralPath 'C:\dane\plik.txt' -ErrorAction Stop. Jeżeli odczyt się nie powiedzie, PowerShell przerywa wykonanie tej instrukcji i przekazuje wyjątek do najbliższego pasującego bloku catch. Jest to istotne w skryptach, w których dalsze operacje zależą od poprawnego wykonania wcześniejszego kroku.
Konstrukcja try-catch-finally w skrypcie
Podstawowa konstrukcja obsługi błędów składa się z bloku try, jednego lub większej liczby bloków catch oraz opcjonalnego bloku finally. W try umieszcza się instrukcje, które mogą wygenerować wyjątek. W catch definiuje się reakcję na niepowodzenie, a finally wykonuje się po zakończeniu próby, niezależnie od tego, czy błąd wystąpił. Przykładowy schemat wygląda następująco: try { Get-Content -LiteralPath 'C:\dane\plik.txt' -ErrorAction Stop } catch { Write-Error "Nie udało się odczytać pliku: $($_.Exception.Message)" } finally { Write-Verbose 'Zakończono próbę odczytu' }.
W bloku catch zmienna $_ reprezentuje bieżący obiekt błędu, którego typem jest ErrorRecord. Właściwość Exception zawiera wyjątek zgłoszony przez polecenie, a Exception.Message jego komunikat. Przy analizie problemu przydatne są także właściwości CategoryInfo, FullyQualifiedErrorId oraz TargetObject. Można przechwytywać wyłącznie określony typ wyjątku, na przykład catch [System.IO.FileNotFoundException], a następnie użyć ogólnego catch dla pozostałych przypadków. Bardziej szczegółowy blok powinien znajdować się przed ogólnym, ponieważ obsługa jest sprawdzana w kolejności występowania.
ErrorAction, ErrorVariable i kontrola dalszego przebiegu
Parametr -ErrorAction jest wspólnym parametrem wielu poleceń PowerShell i określa reakcję na błędy. Wartość Stop zmienia błąd nieterminujący w terminujący. Continue wyświetla błąd i kontynuuje działanie, natomiast SilentlyContinue pomija jego wyświetlenie, ale nie usuwa problemu z logiki wykonania. Wartość Ignore również pomija komunikat, a dodatkowo nie zapisuje błędu w automatycznej zmiennej $Error. Stosowanie SilentlyContinue lub Ignore bez dodatkowej kontroli może ukryć przyczynę nieprawidłowego działania.
Do zapisania informacji o błędzie w osobnej zmiennej służy parametr -ErrorVariable, na przykład Get-Item -LiteralPath 'C:\brak' -ErrorAction SilentlyContinue -ErrorVariable problem. Zawartość można później sprawdzić przez $problem. Globalna zmienna $Error przechowuje historię obiektów błędów w bieżącej sesji, przy czym najnowszy błąd znajduje się na początku kolekcji. Dla większej kontroli skrypt może ustawić lokalnie preferencję $ErrorActionPreference = 'Stop', ale taka zmiana wpływa na kolejne polecenia w danym zakresie. Zwykle bezpieczniej jest używać -ErrorAction Stop przy konkretnych operacjach, których powodzenie warunkuje dalszy przebieg.
Obsługa błędów powinna także określać, co ma stać się po przechwyceniu wyjątku. Możliwe jest zapisanie komunikatu, zwrócenie kontrolowanego wyniku, ponowne zgłoszenie problemu przez throw albo zakończenie skryptu z kodem wskazującym niepowodzenie. Samo wyświetlenie komunikatu nie oznacza, że operacja została naprawiona. Jeżeli błąd ma zostać przekazany wyżej, użycie throw zachowuje semantykę nieudanego wykonania i pozwala nadrzędnemu fragmentowi skryptu zareagować właściwie.
Znaczenie obsługi błędów przy pracy na komputerze
Nieprawidłowa obsługa błędów w PowerShell może powodować pozornie poprawne wykonanie skryptu mimo pominięcia ważnej operacji. Przykładowo skrypt może nie odczytać pliku konfiguracyjnego, a następnie uruchomić kolejne polecenia z pustą wartością. Dlatego przy diagnostyce należy sprawdzić, czy operacje wejścia i wyjścia mają odpowiednie -ErrorAction, czy komunikaty z catch zawierają rzeczywistą przyczynę z Exception.Message oraz czy blok finally nie maskuje wcześniejszego błędu. Warto również rozdzielić komunikaty diagnostyczne od danych wyjściowych skryptu, wykorzystując między innymi Write-Verbose, Write-Warning i Write-Error.
Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów, komputerów PC i ich podzespołów, gdy problemy z wykonywaniem skryptów PowerShell wynikają z nieprawidłowej konfiguracji systemu, uszkodzenia instalacji oprogramowania albo innych usterek komputera. Przy ocenie problemu znaczenie ma odtworzenie błędu, sprawdzenie komunikatów PowerShell oraz ustalenie, czy przyczyną jest sam skrypt, uprawnienia, dostęp do ścieżki czy stan systemu.
