Zdarzenie On Failure

Zdarzenie On Failure uruchamia kolejny krok zadania wyłącznie w przypadku niepowodzenia poprzedniego.

Na czym polega zdarzenie On Failure

Zdarzenie On Failure jest warunkiem sterującym w zadaniu złożonym z kilku kroków. Powiązany z nim kolejny krok zostaje uruchomiony wtedy, gdy wcześniejsza operacja zakończy się statusem niepowodzenia. Nie jest to zwykłe przejście wykonywane po każdym zakończeniu. System rozróżnia co najmniej rezultat poprawny i błędny, a logika On Failure reaguje wyłącznie na ten drugi stan. Dzięki temu można oddzielić normalną ścieżkę działania od obsługi problemu.

Przykładowy przepływ może obejmować próbę utworzenia kopii pliku, sprawdzenie jej wyniku oraz wysłanie komunikatu o błędzie. Jeżeli kopiowanie zakończy się powodzeniem, następny etap głównego zadania może zostać wykonany zgodnie z normalnym planem. Jeżeli natomiast operacja zwróci błąd, gałąź On Failure może zapisać szczegóły zdarzenia, ponowić próbę albo przekazać informację do użytkownika. Samo zdarzenie nie naprawia przyczyny awarii; jedynie pozwala uruchomić zdefiniowaną reakcję.

Jak system rozpoznaje niepowodzenie

Warunek On Failure działa na podstawie statusu zwróconego przez poprzedni krok. W zależności od używanego programu takim statusem może być kod zakończenia procesu, wyjątek, przekroczenie limitu czasu, brak wymaganego pliku, odrzucenie operacji przez sterownik albo jawne oznaczenie zadania jako nieudanego. Istotne jest, aby błąd rzeczywiście został przekazany do mechanizmu sterującego. Program, który wyświetli komunikat o problemie, ale zakończy się kodem powodzenia, może nie uruchomić ścieżki On Failure.

W praktyce trzeba także odróżnić błąd kroku od błędu całego zadania. Niektóre narzędzia traktują pojedynczy ostrzegawczy komunikat jako stan częściowo poprawny, inne uznają go za niepowodzenie. Znaczenie może mieć również obsługa wyjątków, ustawienie automatycznych ponowień oraz sposób interpretowania kodów zwracanych przez polecenia. Jeżeli krok ma wbudowany mechanizm retry, zdarzenie On Failure może zostać wywołane dopiero po wyczerpaniu wszystkich prób, a nie po pierwszym chwilowym błędzie.

Retry, kolejność i diagnostyka przepływu

Ścieżka uruchamiana po niepowodzeniu powinna mieć jasno określony cel. Ponowienie operacji ma sens przy problemach przejściowych, takich jak chwilowa niedostępność zasobu, zajęty plik lub krótkotrwała utrata połączenia. Przy błędzie trwałym, na przykład braku uprawnień, uszkodzonym systemie plików albo niezgodnym formacie danych, kolejne próby mogą tylko wydłużyć wykonanie zadania. Z tego powodu warto ustalić liczbę ponowień, odstęp między nimi oraz warunek ostatecznego przerwania.

Podczas diagnozowania należy sprawdzić pełną kolejność zdarzeń: moment rozpoczęcia kroku, jego parametry, komunikat błędu, kod zakończenia, liczbę wykonanych prób oraz czas uruchomienia gałęzi On Failure. Trzeba również zweryfikować, czy obsługa błędu sama nie kończy się niepowodzeniem. Przykładowo zapis logu może nie udać się z powodu braku miejsca na dysku, a komunikat może nie zostać wysłany, gdy usługa sieciowa jest niedostępna. W dobrze zaprojektowanym przepływie każdy taki etap ma jednoznaczny status, a log zawiera informacje pozwalające odtworzyć decyzję systemu.

Błędem logicznym jest umieszczenie połączenia On Failure w taki sposób, że prowadzi ono do kroku wykonywanego również na ścieżce poprawnej, bez rozróżnienia rezultatów. Może to powodować podwójne powiadomienia, wielokrotne przetwarzanie tego samego pliku albo nadpisanie informacji o pierwotnej przyczynie. Należy też kontrolować zależności między krokami: jeżeli krok awaryjny wymaga danych, których poprzednia operacja nie utworzyła, reakcja będzie nieskuteczna. Czytelny diagram zależności i osobne komunikaty dla sukcesu, ostrzeżenia oraz błędu ułatwiają wykrycie takich problemów.

Znaczenie przy serwisowaniu komputera

W komputerze domowym lub biurowym nieprawidłowo działające zadania automatyczne mogą objawiać się powtarzającymi komunikatami, brakiem kopii plików, nieudanymi aktualizacjami albo uruchamianiem procedur naprawczych mimo poprawnego wykonania wcześniejszego etapu. Przy analizie takiego przypadku trzeba porównać konfigurację zadania z wpisami w dzienniku systemowym i ustalić, jaki konkretnie status otrzymał poprzedni krok. Pomocne jest także ręczne wykonanie tej samej operacji oraz sprawdzenie miejsca na dysku, uprawnień i dostępności wskazanych ścieżek.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC oraz podzespołów, w tym diagnostyką problemów z automatycznymi zadaniami i błędnymi przepływami operacji.