Jeśli znasz ogólne zasady obsługi błędów w powershell, to nie odkryję tutaj dla Ciebie żadnej nowej filozofii. Jeśli jednak szukasz ogólnej informacji „jak poradzić sobie z błędem w skrypcie” to czytaj dalej.
Zaczynamy od
Import-Module sqlps
Wypróbuj działanie komend wybierających kontekst nieistniejącego serwera SQL lub nieistniejącej bazy danych:
Set-Location SQLSERVER:\localhost\default\databases\foobardb -ErrorAction Stop;
Write-Host -foregroundcolor Yellow „Here next command”
W tym przypadku powinna się wyświetlić informacja o błędzie, ale komunikat z Write-Host nie wyświetli się. ErrorAction Stop oznacza, że po błędzie zatrzymujemy działanie skryptu. Popatrz na drugi przykład:
Set-Location SQLSERVER:\localhost\default\databases\foobardb -ErrorAction Continue;
Write-Host -foregroundcolor Yellow „Here next command”
Teraz komunikat o błędzie też się wyświetlił, ale linijka Write-Host też się wykonała, bo ErrorAction Continue oznacza, że mimo błędu skrypt ma być kontynuowany. I trzeci przykład:
Set-Location SQLSERVER:\localhost\default\databases\foobardb -ErrorAction SilentlyContinue;
Write-Host -foregroundcolor Yellow „Here next command”
(Chcesz wiedzieć więcej? Zobacz lekcję o parametrze ErrorAction dostępną za darmo w ramach kursu Powershell dla administratora Windows)
Teraz nie było komunikatu o błędzie, a linijka Write-Host się wykonała. Tak działa opcja ErrorAction SilentlyContinue – problem zamiatamy pod dywan, nikomu nie mówimy o tym, że doszło do błędu, ot po prostu kontunuujemy jakby błędu nie było.
Nieważne, czy błąd pokazujesz, czy nie informacje o nim możesz znaleźć korzystając z:
- zmiennej $? – zmienna po błędzie przyjmuje wartość $false. Myśl sobie o niej jako o zmiennej która określa czy wykonanie poprzedniej komendy zakończyło się poprawnie. Sprawdzenie zmiennej $? powinno być wykonane natychmiast po potencjalnym błędzie, bo proste wykonanie Write-Host jeśli się powiedzie zmieni wartość tej zmiennej na $true…
- $Error to tablica zawierające listę ostatnich błedów. $Error[0] to ostatni błąd do jakiego doszło. Możesz z tej zmiennej odczytać szczegóły błędu.
No to teraz do rzeczy. Jak obsłużyć błąd. Dwie metody – najpierw gorsza potem lepsza:
Set-Location SQLSERVER:\localhost\default\databases\foobardb -ErrorAction SilentlyContinue;
if(!$?)
{
Write-Warning $Error[0].Exception
}
Tutaj wykonujemy potencjalnie niebezpieczną metodę. Zaraz po niej sprawdzamy zawartość zmiennej $?. Kiedy jest to $false to wyświetlamy ostrzeżenie o błędzie podając więcej szczegółów na temat błędu na podstawie zmiennej $Error[0]. Potencjalnie w tym miejscu można by wykonać więcej czynności i obsłużyć błąd. Zauważ opcję ErrorAction SilentlyContinue. Sami obsługujemy błąd, więc chcemy aby po błędzie kontynuować i żeby błędu nie pokazywać użytkownikowi. Wartość Continue też by zadziałała, ale błąd będzie od razu wyświetlony na ekranie. Opcja Stop spowodowałaby przerwanie skryptu w przypadku błędu i instrukcja if nigdy by się nie wykonała….
A teraz drugie rozwiązanie:
try
{
Set-Location SQLSERVER:\localhost\default\databases\foobardb -ErrorAction Stop;
}
Catch
{
Write-Warning $Error[0].Exception
}
Korzystamy z instrukcji try/catch. Potencjalnie niebezpieczne instrukcje lądują w bloku try. Gdy dojdzie do błędu blok try ma się przerwać a obsługę zorganizujemy w bloku catch. I tu drobna uwaga. W bloku try musisz użyć opcji ErrorAction Stop. Błąd ma bowiem powodować przerwanie działania instrukcji w bloku try.
