Debugowanie R nie należy do najprzyjemniejszych, ale zarówno RStudio, jak i zmiany w R w wersji 3.1 przyniosły wiele dobrego - trzeba się tylko nauczyć, jak z tego korzystać.
W dalszej części korzystać będę z nomenklatury RStudio, czyli np. mówić o breakpoint-ach bez wchodzenia w to, jak tak naprawdę są one realizowane na poziomie R.
Podczas wykonywania krokowego nie ma długo nie było łatwego sposobu na przejście do krokowego wykonywania wywoływanej funkcji (brak komendy step into debugera).
W R 3.1 już można!
Możliwe obejścia we wcześniejszych wersjach:
Pisząc pakiety R, w szczególności base i stat, mało kto przejmuje się eleganckim zgłaszaniem błędów. Stąd błędy zgłaszane przez funkcje języka R na ogół odnoszą się do tego, co poszło nie tak wewnątrz danej funkcji, a nie co było nie tak w przekazanych jej parametrach, a więc niewiele mówią.
Z problemem tym stykamy się także podczas domyślnego wchodzenia w tryb debugowania przez RStudio - na ogół na ekranie wyświetlany jest nam kod jakiejś wewnętrznej funkcji R w której ostatecznie błąd się ujawnia. My tymczasem wolelibyśmy zobaczyć kod naszej funkcji, wraz ze wskazaniem linii, w której tą wewnętrzną funkcję R wywołaliśmy.
Szczęśliwie:
Możemy się tam dowiedzieć:
RStudio nie umie rozpoznać sytuacji, w której kod funkcji z breakpoint-em został przykryty przez inny kod. Typowo sekwencja zdarzeń wygląda następująco:
Dzieje się tak dlatego, że breakpoint można założyć tylko w kodzie wczytanym z pliku (takie są techniczne ograniczenia R), a obecny kod funkcji X() nie pochodził z wczytania danych z pliku, tylko został wprost wpisany w konsoli R.
Żeby pozbyć się problemu: