On Error GoTo

On Error GoTo to instrukcja VBA przekierowująca wykonanie do etykiety obsługi błędu.

On Error GoTo — czym jest przekierowanie obsługi błędu w VBA

On Error GoTo jest elementem języka VBA, który pozwala zaplanować reakcję procedury na błąd wykonania. Zamiast natychmiastowego przerwania makra można wskazać etykietę znajdującą się w tej samej procedurze. Po wystąpieniu problemu sterowanie przechodzi do oznaczonego miejsca, gdzie można rozpoznać sytuację, zapisać informacje diagnostyczne, wyświetlić komunikat albo bezpiecznie zakończyć działanie kodu.

Typowa konstrukcja składa się z instrukcji włączającej obsługę oraz etykiety zapisanej z dwukropkiem. Przykładowy schemat wygląda następująco:

Sub PrzetworzDane()
    On Error GoTo ObslugaBledu
    ' kod główny procedury
    Exit Sub

>ObslugaBledu:
    ' reakcja na błąd
End Sub

Etykieta ObslugaBledu: nie jest nazwą specjalną narzuconą przez VBA. Może zostać zastąpiona innym identyfikatorem, jednak nazwa powinna jasno określać przeznaczenie danego fragmentu. Instrukcja Exit Sub, Exit Function albo Exit Property przed etykietą ma istotne znaczenie. Zapobiega przypadkowemu przejściu do sekcji obsługi błędu po prawidłowym wykonaniu kodu.

W praktyce On Error GoTo nie naprawia przyczyny problemu. Zapewnia kontrolowany sposób przejęcia sterowania, gdy operacja nie może zostać wykonana. Rzeczywista jakość rozwiązania zależy od tego, czy błąd zostanie właściwie zidentyfikowany i czy procedura pozostawi dane oraz obiekty w spójnym stanie.

On Error GoTo i kontekst techniczny: etykieta, zakres oraz przepływ wykonania

Obsługa błędów w VBA działa w zakresie pojedynczej procedury. Jeżeli instrukcja On Error GoTo ObslugaBledu znajduje się w procedurze Sub, wskazana etykieta musi być dostępna w tej procedurze. Nie można traktować etykiety jak globalnego punktu, do którego da się przejść z dowolnego modułu. Taki zakres ogranicza nieprzewidywalne skoki i ułatwia analizę kodu.

Występują trzy podstawowe tryby reakcji na błędy. On Error GoTo nazwa aktywuje przejście do konkretnej etykiety. On Error Resume Next nakazuje kontynuować wykonywanie od instrukcji następującej po tej, która spowodowała problem. On Error GoTo 0 wyłącza aktywną obsługę błędów w bieżącej procedurze. Te tryby nie są równoważne i powinny być dobierane do rodzaju operacji.

W porównaniu z Resume Next wariant z etykietą daje większą kontrolę nad końcowym przebiegiem procedury. Pozwala zebrać numer błędu z właściwości Err.Number, opis z Err.Description oraz źródło z Err.Source. Z kolei Resume Next bywa przydatne przy krótkich, opcjonalnych operacjach, ale może ukryć problem, jeśli po pominięciu instrukcji kolejne fragmenty nadal zakładają, że operacja zakończyła się powodzeniem.

Warto rozróżnić obsługę błędu wykonania od sprawdzania danych wejściowych. Nieprawidłowy format tekstu, puste pole lub brak zaznaczenia można często wykryć warunkiem If jeszcze przed wykonaniem ryzykownej instrukcji. On Error GoTo powinno pozostawać zabezpieczeniem dla sytuacji, których nie da się wiarygodnie przewidzieć samymi warunkami, takich jak niedostępny plik, konflikt typu danych albo problem z obiektem.

Po przejściu do etykiety działanie błędu pozostaje aktywne do chwili wyłączenia lub opuszczenia procedury. Jeżeli w samej sekcji obsługi zostanie wykonana kolejna instrukcja powodująca błąd, może dojść do kolejnego problemu zamiast do przejrzystego zakończenia. Dlatego kod porządkujący zasoby powinien być prosty, a w razie potrzeby należy użyć On Error GoTo 0 przed wykonaniem niezależnych operacji kontrolnych.

On Error GoTo — typowe problemy w procedurach VBA

Częstym błędem jest brak wyjścia z procedury przed etykietą. W takim układzie kod główny wykonuje się poprawnie, a następnie przechodzi liniowo do sekcji opisanej jako obsługa błędu. Może wtedy zostać wyświetlony komunikat o awarii mimo braku awarii albo wykonane zostaną czynności przeznaczone wyłącznie dla sytuacji wyjątkowej. Zastosowanie Exit Sub lub odpowiednika dla funkcji rozdziela normalny przebieg od ścieżki awaryjnej.

Drugim problemem jest zbyt szeroka obsługa obejmująca całą, rozbudowaną procedurę. Gdy kilkadziesiąt operacji znajduje się pod jednym On Error GoTo, sama etykieta nie wskazuje, która czynność spowodowała problem. Utrudnia to diagnozę i może prowadzić do błędnych komunikatów. Lepszy efekt daje podział większej procedury na mniejsze funkcje albo ograniczenie zakresu obsługi do fragmentu, w którym rzeczywiście może wystąpić przewidywalny błąd.

Niewłaściwe stosowanie On Error Resume Next również osłabia kontrolę nad kodem. Jeżeli ten tryb pozostanie aktywny przez dłuższy fragment, błędy mogą być cicho pomijane, a zmienne mogą zachować wartości domyślne. Bezpośrednio po krótkiej operacji opcjonalnej warto sprawdzić Err.Number, wykonać potrzebną reakcję, a następnie wyłączyć tryb przez On Error GoTo 0.

Problemy pojawiają się także wtedy, gdy po wystąpieniu błędu kod odwołuje się do właściwości Err dopiero po wykonaniu wielu kolejnych instrukcji. Informacje o ostatnim błędzie mogą zostać zmienione przez następną operację. Najbezpieczniej jest od razu przechwycić numer i opis do zmiennych, jeśli będą potrzebne w dalszej części procedury.

Nie powinno się również wyświetlać użytkownikowi surowego, technicznego opisu w każdej sytuacji. W komunikacie końcowym można podać zrozumiałą informację, a szczegóły zapisać do arkusza diagnostycznego, pliku tekstowego lub rejestru zdarzeń. Taki podział ułatwia korzystanie z makra i jednocześnie zachowuje dane potrzebne do ustalenia przyczyny.

On Error GoTo — praktyczne wskazówki projektowania obsługi

Przed napisaniem etykiety warto ustalić, co ma stać się po błędzie. Możliwe scenariusze obejmują ponowienie operacji, pominięcie pojedynczego rekordu, zamknięcie otwartego pliku, przywrócenie ustawień aplikacji albo zakończenie procedury z komunikatem. Sama obecność obsługi nie gwarantuje poprawności. Należy określić, które obiekty zostały utworzone, które zasoby wymagają zwolnienia i czy częściowo zmienione dane powinny zostać zachowane.

Dobrym wzorcem jest przechwycenie informacji o błędzie, wykonanie krótkiej sekcji porządkującej oraz wyjście z procedury. W procedurach zwracających wartość trzeba dodatkowo ustalić, jaka wartość oznacza niepowodzenie. Przykład może wyglądać następująco:

Function PobierzWynik() As Variant
    On Error GoTo Blad
    PobierzWynik = Arkusz1.Range("A1").Value
    Exit Function

Blad:
    PobierzWynik = Empty
End Function

W bardziej rozbudowanym rozwiązaniu można oddzielić logikę biznesową od komunikowania błędów. Funkcja niższego poziomu może przekazać informację wyżej, natomiast procedura sterująca zdecyduje, czy pokazać komunikat, zapisać zdarzenie, czy kontynuować przetwarzanie. Należy przy tym pamiętać, że błąd nie powinien być bezrefleksyjnie ukrywany tylko dlatego, że procedura ma działać dalej.

Przy testowaniu warto sprawdzić kilka odmiennych przypadków: brak pliku, zablokowany plik, pustą wartość, tekst zamiast liczby, nieistniejący zakres oraz przerwanie operacji przez użytkownika. Każdy scenariusz powinien prowadzić do przewidywalnego zakończenia. Szczególną uwagę należy zwrócić na komunikaty, ponieważ ich treść często ujawnia, czy błąd został przechwycony w odpowiednim miejscu.

Pomocne jest także stosowanie jednolitego nazewnictwa etykiet, na przykład BladOdczytu, BladWalidacji lub BladZapisu. Nazwa nie zastąpi dokumentacji, ale ułatwi szybkie odczytanie intencji kodu. W komentarzu można krótko opisać, jakie sytuacje są obsługiwane i jakie warunki muszą być spełnione przed opuszczeniem procedury.

Kiedy On Error GoTo wymaga sprawdzenia w serwisie komputerowym

Problemy z makrami VBA mogą wynikać nie tylko z samej składni instrukcji, lecz także z uszkodzonego pliku, niezgodności dodatków, blokad zabezpieczeń, błędnych odwołań do bibliotek lub niestabilnego działania środowiska systemowego. Jeżeli błąd pojawia się w wielu dokumentach, występuje po zmianie konfiguracji albo towarzyszą mu zawieszanie programu i utrata danych, przydatne może być sprawdzenie całego stanowiska oraz kopii plików.

Do serwisu można zgłosić komputer, na którym makra przestały działać, procedury zamykają aplikację albo dokumenty otwierają się nieprawidłowo. Przydatne jest przekazanie opisu czynności poprzedzających błąd, nazwy używanej aplikacji oraz kopii zapasowej dokumentu, o ile nie zawiera poufnych danych. Kontakt z Warszawskim Pogotowiem Komputerowym 24/7 jest możliwy pod numerem +48 22 100 48 29.

Przed przekazaniem pliku warto wykonać kopię, zapisać dokładny komunikat i zanotować, czy problem występuje po każdym uruchomieniu, czy tylko dla określonych danych. Takie informacje ułatwiają odróżnienie błędu w kodzie On Error GoTo od problemu z plikiem, dodatkiem lub konfiguracją programu. Dzięki temu można szybciej ustalić, czy wystarczy korekta procedury, czy potrzebne jest szersze sprawdzenie komputera.