TRANSKRYPCJA

Witam serdecznie, nazywam się Paweł Niemyt, jestem trenerem Altkom Akademii, na co dzień zajmuję się szkoleniami z Visual Basica w Excelu, z SQL-a, z zarządzania projektami, głównie z narzędzi wspierających w zarządzaniu projektami, takich jak np. Project czy Jira. Dzisiaj chciałbym powiedzieć parę słów apropos obsługi błędów w Visual Basicu w Excelu; czyli jak radzić sobie kiedy nastąpi coś niespodziewanego w Visual Basicu.

Jeżeli chodzi o błędy, no to one zawsze mogą nastąpić, natomiast chodzi o to żeby zminimalizować ryzyko, że stanie się coś niespodziewanego. Niestety nie da się wszystkich rzeczy przewidzieć. Nasz kod może być idealny, ale i tak może się zdarzyć coś czego się nie będziemy spodziewać no i wtedy co się dzieje?

W tym momencie następuje błąd. Jeżeli w naszym kodzie następuje błąd, to co się dzieje z naszym kodem? Nasz kod się wysypie. No i właśnie tu dzisiaj chciałbym żebyśmy powiedzieli sobie parę słów jak sobie z tym radzić. Zacznijmy od tego, że przejdziemy sobie do edytora; możemy też przejść za pomocą skrótu, alt+f11 i wtedy wejdziemy bez wchodzenia, czyli przez zakładkę developer.

Mamy otwarty cały plik, dodamy sobie tutaj nowy moduł, w którym to tworzymy sobie taką prostą procedurę. Błędy możemy podzielić na kilka rodzajów – na błędy składniowe, błędy logiczne, błędy wykonania. My się tu jednak zajmiemy błędami wykonania.

O błędach składniowych nie będziemy za dużo mówić bo wiadomo, jeżeli błąd składniowy jest, czyli tak zwany syntax zero, jeżeli mamy błąd w kodzie, to kod i tak się nie odpali. Natomiast może się zdarzyć, że nasz kod nie ma błędów, żadnych składniowych, natomiast po odpaleniu wyskoczy błąd.

Jaki? Na przykład może być sytuacja taka, w której chcemy na przykład utworzyć plik, którego nie ma, który wcześniej usunięto. No to co zrobi nasz program? Jeżeli w jakiś sposób tego nie oprogramujemy, czyli tego nie zabezpieczymy, to się nie wykona.

Może zdarzyć się coś takiego, że będziemy chcieli zaznaczyć arkusz, ale ktoś go wcześniej usunął. Będziemy chcieli wybrać jakiś arkusz w Excelu, ale się okaże, że ktoś zmienił jego nazwę. Jeżeli nie ma zabezpieczenia żadnego w naszym kodzie, to w tym momencie program nie myśli, nie będzie wiedział co zrobić więc co, więc się wysypie.

Jeżeli chodzi o Visual Basic for Applications, czyli VBA w Excelu, sytuacja wygląda tak, że nasz kod kompiluje się i wykonuje w locie – czyli w momencie gdy się kompiluje, to też się wykonuje więc jeżeli na przykład nastąpi jakiś błąd, to do momentu wystąpienia błędu wszystkie rzeczy się wykonają. Niesie to ze sobą pewne ryzyko bo może być tak, że poniżej tej linijki kodu może być sytuacja, w której na przykład coś sprawdzamy jeszcze i on do tego momentu w ogóle nie dojdzie.

Chciałbym żebyśmy od razu tu jakiś przykład błędu sobie wygenerowali więc stworzę prostą procedurą, proste makro, które taki błąd wygeneruje. Nazwiemy to jakoś „Sprawdzenie”. No i będzie proste polecenie, na przykład weźmiemy sobie, w moim pliku jest jeden arkusz, natomiast ja sobie wezmę worksheets, kolekcja arkuszy, wybiorę sobie arkusz na przykład dwunasty, którego tu nie ma i go aktywuję.

No i zobaczmy co się stanie jak kod odpalę – następuje błąd. Tutaj możemy wejść w help, otworzy nam się strona na której mamy opis błędu. Wrócimy do Excela, możemy sobie o tym poczytać, nie mamy na to teraz czasu, możemy kliknąć debug, debug nam pokaże moment, w którym błąd wystąpił.

Nie oznacza to wcale, że w tym kodzie to jest jedyne miejsce gdzie jest błąd. Pokazuje nam pierwsze wystąpienie jakiegokolwiek błędu. Póki tego błędu nie naprawimy, to nasz kod nie będzie kontynuował. Jeszcze raz uruchomienie tego kodu spowoduje wystąpienie znowu tego samego błędu.

Możemy kliknąć end, end powoduje, że nam automatycznie przeskakuje do endsa, czyli nasz kod w tym momencie wisi.Jeżeli bym sobie tutaj wpisał message boxa, tekstem test, to póki tego błędu nie wyeliminuję, ten test nigdy się nie wykona. Nie ma opcji żebym mógł przejść do tego testu. Dlaczego?

Dlatego, że mamy tutaj błąd, który mi blokuje całą resztę kodu. Póki go nie naprawię, ten kod nie będzie kontynuowany – no i może być problem, tak, jeżeli to jest na przykład jakieś makro, które importuje dane skądś no i jest tak, że ono te dane najpierw importuje, a potem sprawdza, czy te dane zaimportowane są poprawne, to w ten oto sposób może być taka sytuacja, która, jak wystąpi nam w trakcie importowania błąd, to tutaj do sprawdzenia nie będziemy mieć, tak, no i teraz jeżeli użytkownik nie zauważy tego błędu no bo po prostu kliknie tam byle co żeby mu się tylko to zamknęło i dane jakieś już tam się zaimportują, stwierdzi, że jest wszystko w porządku, wyśle te dane gdzieś i się okaże, że są błędy.

Niesie to ze sobą takie ryzyko, że, pomijając fakt, że nam kod się przerwie, może nie do końca być to wszystko tam poprawnie co jest. Nawet jeżeli już jakaś część się wykona. Co warto zrobić? W każdej naszej aplikacji, mniej lub bardziej rozbudowanej, warto zastosować tak zwaną obsługę błędów.

Obsługa błędów polega na tym, ze możemy te błędy przechwytywać i coś z nimi robić. Możemy na przykład użytkownika przenieść w jakieś bezpieczne miejsce, możemy na przykład zrobić coś takiego, że jeżeli ten błąd wystąpi no to wyświetli się komunikat, który powie żebym skonsultował się z administratorem albo wycofa wszystkie te zmiany, które zaszły. Chodzi po prostu o to, ze możemy zareagować na wystąpienie tego błędu.

Jak to się robi? Przed pierwszym wystąpieniem tego błędu trzeba dać polecenie on error, resume, next. Jeżeli takie coś zapiszemy, to oznacza to, że od tego momentu wszystkie błędy będą ignorowane. Zobaczmy, że jak teraz odpalę to makro, wyświetli się komunikat.

Widzimy? Test. Mimo, że ta linijka jest błędna, wcale nie oznacza, że się ona wykonała, ona nadal się nie wykonuje, nadal jest błędna. Nie aktywuje mi się arkusz dwunasty, arkusza, którego nie ma, natomiast on ignoruje ten błąd, nie wykona oczywiście tego i przechodzi dalej. Czyli jakby pierwsza taka, można powiedzieć, „zaleta”, że jeżeli takie coś zapiszemy, to w tym momencie błędy nam nie przeszkadzają.

Dlaczego? Dlatego, że, tak czy siak, te dane na przykład są do połowy tylko zaimportowane i to nadal nie wiadomo tak naprawdę co z tym fantem zrobić, tak. Więc co trzeba by zrobić? Trzeba by jakoś zareagować na ten błąd i poinformować wtedy, że ten błąd istnieje. Więc co możemy zrobić? Możemy zrobić coś takiego, ze mamy napisać warunek if no i teraz jak sprawdzić, czy jest błąd?

Mamy coś takiego jak r, jest to obiekt, który, jeżeli jakiś błąd wystąpi, potrafi sobie zwrócić jakąś tam wartość, ma różne właściwości, jedną z nich jest na przykład number, czyli zwraca nam numer błędu. Jeżeli error number jest równy zero, znaczy, że w naszym kodzie błędu nie ma.

I teraz możemy to bardzo łatwo sprawdzić – jeżeli w tym message boxie wrzucimy sobie r, to domyślnie jest number, nie musimy tego pisać, możemy oczywiście napisać, ale nie musimy bo to jest domyślna właściwość tego obiektu, no to teraz zobaczmy.

Jak odpalimy nasze makro, następuje numer 9. Jeżeli na przykład tego błędu by nie było, to nam daje bardzo prostą możliwość, a mianowicie żeby to wykorzystać. Możemy dać warunek, że if r jest różne od zera, wtedy, i tutaj jakiś ładny komunikat napiszemy, możemy to nawet dać w jednej linii, wtedy wyświetlimy sobie nasz komunikat, wystąpił błąd, czyli nasz komunikat, możemy dodatkowo zrobić jeszcze jedną rzecz.

Możemy sobie na przykład wyświetlić jaki to błąd wystąpił, możemy zrobić wystąpił błąd, numer, dwukropek, tu damy and, error, number. Możemy też na przykład sobie podzielić ten nasz message box na kilka linijek; piszemy sobie vbnewline i będziemy konutynować w kolejnej linii, error description, czyli będzie opis, wrzucimy sobie jeszcze raz nową linię i standardowy tekst, który w takiej sytuacji się wrzuca – skontaktuj się z, na przykład, administratorem. Albo możemy po prostu podać własnego maila, imię i nazwisko, żeby użytkownik wiedział co ma w tym momencie zrobić.

No i teraz zobaczmy – jak ja to odpalę, nie ma żadnego błędu, użytkownik uruchomił to makro, żadnego błędu nie będzie. Natomiast jeżeli błąd wystąpi no i ten użytkownik będzie chciał sobie to makro uruchomić, no to wystąpi błąd. Nie może wybrać sobie. Ale co się stało? Nasze makro się w żaden sposób nie wysypało, nie wysypało się, kod się nie przerwał więc ten błąd jakoś przechwyciliśmy. Często mamy z tym do czynienia na przykład na stronach internetowych, że nie wyświetla się na przykład błąd 404, tylko na przykład wyświetla się komunikat; uwaga, mam jakiś problem, przerwa techniczna, coś takiego.

To jest właśnie też przekierowanie jakieś bo w rzeczywistości jak się serwer zawiesza, to w tym momencie strona się wysypuje i na przeglądarkę powinien nam się wpisać kod strony, napisany czy w PHP, czy w czymś innym. Natomiast jeżeli jest ta obsługa błędów zachowana, no to jest przechwycenie tego błędu jeżeli jakiś błąd wystąpił, oczywiście serwer tam się, powiedzmy, wysypał, natomiast u nas się wyświetla jakaś strona, że przerwa techniczna, przepraszamy, wrócimy jak tylko się da. Tak samo tutaj – możemy po prostu, w momencie kiedy jakiś błąd wystąpi, tego użytkownika naszego jakoś tak przekierować w bardziej bezpieczne miejsce.

Co możemy jeszcze zrobić? Możemy na przykład zrobić, nadać etykietę, napiszmy sobie, z dużych liter, coś takiego, tak, dać taką etykietę no i teraz tutaj zrobić nie on error, resume, next, tylko go to, no i można sobie to wrzucić. Oznacza to, ze jak jakikolwiek błąd wystąpi, tu by był na przykład jakiś tam message box, niech będzie test, to w tym momencie automatycznie przeskakuje od razu do tej części kodu i wykonuje to co tu jest.

Czyli nie wykona tego nigdy, zobaczmy, nie ma testu. Natomiast jeżeli by było on error, next, to by po prostu ten test też się wyświetlił. Czyli może być sytuacja taka, że jak jakiś błąd nastąpi, że na przykład pliku nie ma, to nie ma robić dalej, tylko ma od razu przejść tutaj, wyświetlić komunikat, że jest błąd no i przerwać działania wokół naszego kodu.

Oczywiście mogą być jakieś jeszcze dodatkowe czynności sprawdzające i ewentualnie jakieś czynności, które powodowałyby, że ten plik się na przykład bezpiecznie zamknie, czy bezpiecznie użytkownik z niego wyjdzie.

Jedna jeszcze ważna rzecz – jeśli tych błędów jest więcej, na przykład jeśli byśmy sobie zrobili coś takiego, że zostawimy sobie na przykład komórkę B2, komentarz, wstawimy sobie komentarz, no i teraz do komórki B2 chciałbym wstawić sobie drugi komentarz, ale już za pomocą kodu, czyli, niech będzie taka zawartość, zobaczmy – odpalamy i mamy błąd nadal numer 9.

Natomiast jeżeli bym sobie ten błąd wykomentował, to będzie błąd 1404. Nie można wstawić za pomocą polecenia add comment dwa razy w jedną komórkę komentarza bo to też generuje błąd. Czyli to też jest takie ryzyko, że możemy za pomocą tego polecenia na przykład wstawiać komentarze, natomiast ktoś wcześniej wstawi ten komentarz no i że jest błąd.

No to co, to może się makro wysypać? Możemy przekierować w bezpieczne miejsce, na przykład jeśli tam był error 1004, to możemy odpowiednika poinformować o tym, że na przykład to nie jest miejsce, w którym powinien to robić.

Więc cała obsługa błędów i cała filozofia tego skupia się po prostu na tym, że jeżeli jakiś błąd wykonania nastąpi, to jesteśmy wtedy w stanie go przechwycić i przekierować do użytkownika w bezpieczne miejsce. I to tyle jeżeli chodzi o obsługę błędów; w ogóle w większości aplikacji jest stosowana, ja dziękuję i zapraszam na szkolenia z VBA.