#Niezbędnik Juniora. Co zrobić, gdy kod się nie kompiluje?

Dzisiejszy wpis, będzie szczegól­nie przy­dat­ny w codzi­en­nej pra­cy z kodem. W szczegól­noś­ci, gdy pojaw­ia­ją się prob­le­my z uru­chomie­niem dopiero co napisanego kodu. A gdy jesteś dopiero na początku swo­jej pro­gramisty­cznej to potrafi przytłoczyć. Dlat­ego śpieszymy z pomocą i pokazu­je­my, co zro­bić, by “napraw­ić” kod.

Ten wpis dedyku­je­my w szczegól­noś­ci początku­ją­cym pro­gramis­tom, jed­nak zebrane przez  artykuły mogą się przy­dać nieza­leżnie od Two­jego stażu.

Po pierwsze, nie panikuj

Musisz się przyzwycza­ić, że pra­ca pro­gramisty pole­ga na pra­cy z kodem, który się nie uruchamia :) Wie, wiem, łat­wo mi to ter­az mówić, ale na początku mojej nau­ki pamię­tam jak error potrafił mnie skutecznie zniechę­cić do dal­szego pro­gramowa­nia, czy myśle­nia, o tym, czemu to nie dzi­ała. Po pros­tu, nie wiedzi­ałam, co robić. Rozwiązanie jest jed­nak prost­sze niż myślisz… Sprawdź, co masz na kon­soli. Wiemy, cza­sem to może być ist­na kaska­da wyjątków, ale my potrze­bu­je­my tylko jed­nego. Wyjątek, który jest najniżej jest przy­czyną Two­jego prob­le­mu i nim będziemy się zajmować.

Po drugie, zrozum, co to oznacza

W miarę zdoby­wa­nia pro­gramisty­cznego doświad­czenia, pojaw­ie­nie się  pewnych wyjątków, będzie miało dla Ciebie oczy­wiste źródła. Jed­nak cza­sem możesz nie wiedzieć, co one oznacza­ją. Co wtedy? Po pros­tu skopi­uj go do google’a i sprawdź, co oznacza. Tutaj pole­camy  1.oficjalną dokumentacje(tutaj lin­ki do doku­men­tacji Javy i Springa) lub 2. Stack­Over­flow. Rekomen­du­je­my naucze­nie się pra­cy z doku­men­tacją, ponieważ bard­zo ułatwi nam to czy­tanie komu­nikatów o błę­dach i zna­j­dowanie rozwiązań. Gwaran­tu­je­my, że po krótkim wyszuki­wa­niu, zna­jdziesz  opis swo­jego prob­le­mu. Ter­az czas na jego analizę.

Po trzecie, znajdź jego przyczynę

Na kon­soli wyp­isane są też inne przy­datne infor­ma­c­je, które przy­bliżą Cię do rozwiąza­nia prob­le­mu —  jak cho­ci­aż­by miejsce, w którym wyjątek się pojaw­ił. Zazwyczaj IDE pozwala prze­jść bezpośred­nio do prob­lematy­cznej lin­ij­ki w kodzie. Prze­jdź do niej i sprawdź w czym problem.

Po czwarte, zrozum swój błąd

Niek­tóre błędy np. literów­ki (które też Two­je IDE powin­no pod­kreślić), brak @Autowired czy domyśl­nego kon­struk­to­ra widać od razu, więc i popraw­ić moż­na je naty­ch­mi­as­towo. Inne błędy wyma­ga­ją dokład­niejszej anal­izy. Wtedy warto sko­rzys­tać z debu­gowa­nia, które opisal­iśmy w lekcji Javy. W ten sposób, może­my dokład­nie sprawdz­ić co lin­ij­ka po lin­i­jce dzieje się w naszej aplikacji i napraw­ić problem.

Cza­sem, może okazać się, że nasz sposób napisa­nia danej metody nie przynosi zakładanych przez nas rezul­tatów. Wtedy warto zapy­tać kogoś ze swo­jego zespołu, albo zadać pytanie na Stacku, poszukać naszego prob­le­mu w Internecie. Ktoś mi kiedyś powiedzi­ał, że jeśli w ciągu 15 min nie jesteś w stanie wygooglać odpowiedzi na swo­je pytanie, to powinieneś zapy­tać kole­gi z pra­cy :) Myślę, że coś w tej metodzie jest i więk­szość pro­gramisty­cznych pytań została już zadana.

Zawsze: zapobiegaj, zamiast leczyć ;)

Co zro­bić, by zmin­i­mal­i­zować ilość wal­ki z wyjątka­mi i naszy­mi błę­da­mi w pro­gramowa­niu? Po pier­wsze, dobrze rozu­mieć swój kod i to, co on robi. W tym celu pole­camy Wam metodę gumowej kaczusz­ki, która naprawdę potrafi pomóc (nawet zaawan­sowanym pro­gramis­tom). Po drugie, pole­camy też czy­tać “cud­zy” kod (w szczegól­noś­ci na początku pro­gramowa­nia), by poz­nać lep­iej pewną logikę i kon­cep­ty, które są uży­wane. A i warto też pisać testy, które pozwala­ją nam sprawdzać dzi­ałanie naszego kodu — bo to, że “nic nie wyrzu­ci” przy uruchami­a­n­iu, nie znaczy wcale, że nasz kod dzi­ała poprawnie.

Tyle teorii, ter­az czas na prak­tykę: poniżej mamy dla Was opis od diag­nozy do rozwiąza­nia prob­le­mu. Prze­jdźmy przez niego razem, by przekon­ać się, że nie jest to trudne. 

Ćwiczenie

Na początku weźmy prosty przykład — Null­Point­erEx­cep­tion w kon­soli. Poniższy przykład jest może zbyt dużym uproszcze­niem, ale jeśli Twój stack trace będzie dłuższy to sposó rozwiązy­wa­nia pozosta­je ten sam — szukamy ostat­niego wyjątku (zaczy­na­jącego się od ‘Caused by…’ jeśli jest ich wiele) i patrzymy w jakiej klasie i w której lin­i­jce błąd się pojawia:

W tym wypad­ku chodzi o klasę KotyAp­pli­ca­tion, 8 lin­ijkę. W Eclipse może­my kliknąć na tą nazwę — prze­niesie nas to w odpowied­nie miejsce.

Oczy­wiś­cie błe­dem w tym wypad­ku jest to, że uży­wamy metody toString() na polu kot, które­mu nie nadal­iśmy żad­nej wartoś­ci (jest więc nullem) — stąd widoczny na kon­soli NullPointerException.

W życiu nieste­ty tak łat­wo nie ma, a w aplikac­jach webowych czy korzys­ta­jąc z frame­worków, błąd może nie wskazy­wać nam konkret­nej linii. Weźmy na przykład taki wyjątek:

Nie ma tutaj odniesienia do żad­nej lin­ij­ki w naszym kodzie. Wystar­czy jed­nak wpisać w google treść wyjątku pomi­ja­jąc nazwy klas specy­ficznych dla naszego pro­jek­tu — w tym wypad­ku szukamy “Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qual­i­fy­ing bean of type [pl.kobietydokodu.web.controller.Kot] found for depen­den­cy” (nie­pogru­bione frag­men­ty pomi­jamy). Pier­wszy wynik w Google daje nam odpowiedź: “First off, you could be miss­ing an anno­ta­tion (@Service or @Component) from the imple­men­ta­tion of” (za http://stackoverflow.com/a/8961439) — i fak­ty­cznie, w tym wypad­ku prob­le­mem było to, że nie mamy beana typu Kot (czyli np. w klasie Kot nie ma adno­tacji @Component, może­my temu zaradz­ić doda­jąc tą adno­tację w tym miejscu)

Mamy nadzieję, że to pod­sumowanie doty­czące rozwiązy­wa­nia prob­lemów ułatwi Wam codzi­en­ną walkę z kodem. A jeśli jesteś dopiero na początku nau­ki, to zapew­ni­amy, że do niekom­pi­lowa­nia da się przyzwycza­ić, a i wyjąt­ki po jakimś cza­sie nie są tak straszne :)