Kurs VBA – cz. 18 – Obsługa błędów

Niezależnie jak dokładnie będziemy pisać program i ile do niego przygotowywać, zawsze pojawią się jakieś błędy. Istnieje szereg czynności, które pozwolą nam się do nich przygotować i lepiej z nimi radzić. Czasem możemy nawet świadomie je wywoływać. Najważniejsze jest jednak, żeby w przypadku błędów program zachowywał się w sposób przewidywalny, tak jak to sobie zaplanowaliśmy. Jest to tak samo ważne jak projektowanie samych procedur.

Do najważniejszych zasad należą:
  1. Dokładne projektowanie programu.
  2. Automatyczne sprawdzanie składni (patrz niżej).
  3. Włączenie Option Explicit (patrz niżej)
  4. Tworzenie małych części kodu.
  5. Tworzenie komentarzy
  6. Testowanie aplikacji
Punktowi numer 6 poświęcona zostanie osobna część kursu.
Poniżej zajmiemy się sytuacjami, w których błąd już się pojawił.

Błędy podczas projektowania

Najprostszy i najczęstszy błąd to zwykła literówka. VBE podczas pisania kodu sprawdza czy wszystkie pisane instrukcje są rozpoznawalne. Wszystkie słowa kluczowe są domyślnie kolorowane na niebiesko. Na tym etapie nie są jeszcze sprawdzane funkcje i nazwy zmiennych.
Jeżeli składnia nie będzie odpowiadać VBE, linia zostanie zaznaczona na czerwono, dodatkowo domyślnie pojawi się msgbox z odpowiednią informacją.
Szybko okazuje się, że ten MsgBox jest bardzo irytujący i jeżeli jeszcze go nie wyłączyłeś to można to zrobić w Tools/Options/Auto Syntax Check. Po wyłączeniu tej opcji nieprawidłowe linie wciąż będą się zaznaczać na czerwono, jednak będziemy mogli łatwo przerwać pisanie linii kodu (na przykład, żeby zadeklarować jakąś zmienną).

Błędy podczas uruchamiania

Podczas uruchamiania programu sprawdzane są nazwy wszystkich procedur. Jeżeli gdzieś w kodzie napiszemy funkcję, która nie jest ani wbudowana, ani napisana przez nas to pojawi się ostrzeżenie i uruchamianie zatrzyma się na nazwie uruchamianej procedury.

Option Explicit

Jeżeli chcemy, żeby w tym momencie Excel sprawdzał także poprawność zmiennych, należy na początku modułu napisać instrukcję Option Explicit. Jest do absolutnie kluczowa rzecz, o czym napiszę za chwilę. Jeżeli chcemy, żeby ta instrukcja pojawiała się automatycznie możemy włączyć: Tools/Options/require Variable Declaration i bezwględnie każdy to powinien zrobić.
Po włączeniu tej opcji każda zmienna / stała musi być zadeklarowana przy pomocy instrukcji odpowiednio Dim lub Const, zanim zostanie użyta. Odpowiedni komunikat pojawi się jeżeli użyjemy zmiennej nie zadeklarowanej.
Co się stanie, jeżeli nie włączymy tej opcji? Nie musimy deklarować żadnej zmiennej. Odpowiednie miejsce w pamięci zostanie dla niej zajęte w momencie pierwszego użycia i przyjmie typ Variant. Na pierwszy rzut oka może być to wygodne. Jednak:
  • Tracimy kontrolę nad typami zmiennych.
  • Przede wszystkim: Narażamy się na błędy związane z literówkami

Spójrzmy na poniższy kod, option explicit nie zostało użyte. Nie musiałem deklarować zmiennej text.

Przy braku Option Explicit powyższy kod wykona się, jednak nic nie pojawi się w okienku MsgBox ponieważ zostaną utworzone dwie różne zmienne: Text i tekst. Przy włączonym zabezpieczeniu VBE ostrzeże nas, że nie zadeklarowaliśmy zmiennej Text, a chcemy z nią cos robić.

Dla mnie Option Explicit ma dodatkową wartość. Zawsze nazywam zmienne używając dużych liter. Następnie piszę zmienne używając tylko małych liter. Jeżeli napisałem zmienną prawidłowo, VBE automatycznie zmienia małe litery na duże zgodnie z definicją. Wiem wtedy, że wpisałem zmienną prawidłowo.
O znaczeniu gc w nazwie opowiem w następnej części kursu.

Błędy podczas wykonywania

Wszelkie błędy uniemożliwiające uruchomienie zostały już usunięte, zajmijmy się więc błędami podczas samego działania programu. Są to błędy, które zwykle przerywają działanie programu.
Powyższa instrukcja zaznacza następny arkusz. Przerywa działanie programu i pokazuje błąd, jeżeli aktualnie zaznaczony arkusz jest już ostatnim (brak następnego do zaznaczenia). Żaden kod więcej się nie wykona.

Przy pomocy poniższej instrukcji, możemy kontynuować wykonanie i zdecydować co się będzie działo w przypadku błędu.

On Error

Powyższa instrukcja występuje w trzech wariantach:

  • On Error GoTo Etykieta
  • On Error Resume Next
  • On Error GoTo 0
On Error GoTo Etykieta jest z reguły umieszczane na początku procedury i działa na wszystkie następujące instrukcje do końca procedury lub wywołania On Error GoTo 0. Instruuje program, że w przypadku błędu sterowanie ma przeskoczyć do etykiety.
 

Po etykiecie musi być zawsze napisany dwukropek. Istotne jest, żeby przed etykietą wstawić Exit Sub. Inaczej nasz kod obsługi błędu wykona się nawet, jeżeli błąd nie nastąpi (spróbuj sam uruchomić ten program bez Exit Sub).
W każdej chwili mamy dostęp do obiektu Err, który zawiera szczegóły problemu. Dzięki temu możemy napisać bardziej ogólną procedurę obsługi. Interesują nas szczególne atrybuty Err.Number i Err.Description. Err.number jest równy zero, dopóki nie zajdzie błąd.
 

On Error Resume Next sprawia, że błędy są ignorowane. W przypadku błędu obiekt Err jest wypełniany i system zaczyna wykonywać następną instrukcję. Przejmujemy w ten sposób całkowitą kontrolę nad wykonywaniem programu i musimy zachować szczególną ostrożność. W ten sposób możemy nawet świadomie wywoływać błędy, spójrzmy na poniższy kod:
 

 Zaznaczany jest następny arkusz, lub pierwszy, jeżeli numer aktualnie zaznaczonego arkusza jest równy liczbie wszystkich arkuszy (czyli zaznaczony już jest ostatni).
Ten sam efekt możemy uzyskać przy pomocy obsługi błędów.
 

Metoda Err.Clear czyści zawartość obiektu Err, kiedy już się uporamy z obsługą błędu.
On Error GoTo 0 przywraca standardową obsługę błędów przez system.
Osobiście mówię, że On Error Goto Etykieta włącza obsługę błędów, (mając na myśli obsługę przez użytkownika) często jednak mówi się też, że ta instrukcja wyłącza obsługę błędów (mając na myśli obsługę przez system). Należy o tym pamiętać rozmawiając z innymi programistami.

Błędy logiczne

Absolutnie największą zmorą programistów są błędy logiczne. Nie powodują one żadnych komunikatów. Kod błędny logicznie zwraca wartości, jednak efekt ostateczny działania programu jest nieprawidłowy z punktu widzenia projektu programu.
Zmaganie z tego typu błędami wymaga doświadczenia i na pewno pomaga debagowanie, o którym napiszę wkrótce, oraz stosowanie dobrych praktyk pisania kodu.
Subskrybuj RSS, lub polub blog na Facebooku aby otrzymywać najnowsze informacje o rozwoju kursu.
Zapraszam do zadawania pytań w komentarzach.

Comments 2

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *