I den sidste post viste jeg hvordan det ser ud at lave en opdatering af køreplanerne. Som endte med at jeg opdagede at der var en fejl i app'en, så opdateringen ikke kan bruges. Jeg tænkte, i forlængelse kunne jeg osse vise hvordan det ser ud at finde og rette en fejl i koden.
Når der sker en fejl i app'en bliver der automatisk sendt en fejlrapport tilbage til en server. Du kan se et eksempel på hvordan sådan en fejlrapport ser ud her. Den indeholder ikke særligt meget men nok til at jeg har noget at gå efter når jeg skal finde årsagen. Derudover, første gang en given fejl sker sender systemet mig automatisk en email, så jeg bliver opmærksom på at der er et problem. Emailen indeholder den samme information som er i rapporten. Så det er lissom der det starter.
Hvis jeg vil have et overblik over alle kendte fejl i systemet bliver de osse gemt i et lagersystem jeg har.
På den måde er jeg ikke afhængig af at søge rundt i min inbox for fejl-information, det er osse gemt samlet med alle detaljer.
I dette tilfælde kan jeg se at fejlen sker i NativeVisitList, og fejlen er Attempt to read from null array. Jeg ved at NativeVisitList er den kode der bygger listerne af afgange. Det passer med at jeg kan huske det skete da jeg kiggede på afgange fra Aarhus H til Odense St. Så der er muligvis et problem med hvordan afgange bliver beregnet.
I A til B er der en skarp opdeling mellem den kode der laver beregninger (f.eks, find afgange fra Aarhus H til Odense St.) og brugergrænsefladen, den del der viser resultaterne til brugeren. Det første jeg gerne ville checke var beregnings delen. For at kunne teste den del har jeg en udgave af A til B der slet ikke har en brugergrænseflade, som hedder atb. Den kan det samme som app'en men viser bare resultatet som tekst. Det første jeg forsøger er at bruge atb til at vise den liste afgange som gav problemer.
Det er lidt mere omstændigt end at gøre det gennem app'en, jeg kan f.eks ikke bare få vist afgangene men skal først slå forskellige kodenumre op. Det gør app'en osse men det sker bag kulisserne. Det viser sig at der ingen problemer er – den kan sagtens vise både 10, 100, og 1000 afgange. Det tyder på at problemet er i den kode der viser resultatet.
Brugergrænsefladen til android laver jeg i Android Studio så der kan jeg prøve at køre den komplette app og fange fejlene i en debugger.
Jeg kan ikke genskabe problemet på samme måde som da det først skete hvilket tyder på at fejlen er det man kalder nondeterministisk – fejlen opstår sådan lidt tilfældigt og der er ikke noget du kan gør som fremprovokerer den på den samme måde hver gang. Men det lykkes at finde den et andet sted, nu færgen fra Sælvig til Hou.
Problemet er at der på et tidspunkt mangler et stykke data som koden forventer findes. Jeg prøver at holde øje med hvor det data kommer fra og det viser sig at være en liste som tilfældigvis er tom. Så det er bare et spørgsmål om at noget kode (jeg ikke har skrevet) har valgt at repræsentere en tom liste som at listen slet ikke er der, i modsætning til at der er en liste men listen har ikke nogen elementer. Det er lissom, forestil dig at jeg skal ud og købe ind og beder dig om en liste af ting du skal bruge. Det koden gjorde svarede til at hvis ikke du mangler noget svarer du "nej tak, ikke noget til mig" og giver mig ingen liste. Det min kode forventede svarer til at du altid giver mig en liste, selv hvis ikke du skal bruge noget, der giver du mig bare et tomt stykke papir. (Man skal muligvis være indoktrineret programmør for at det giver mening, men det er altså forklaringen). Begge måder at gøre det giver mening, problemet opstår fordi mine forventninger var forkerte – eller nærmere at det ikke var noget jeg nogensinde havde overvejet.
Det er ikke en ny fejl, den er osse til stede i sidste version f.eks, men man ser den kun hvis man rammer lige i starten eller slutningen af en køreplan, det er der listen er tom, og langt det meste af tiden er man et eller andet sted midt inde i den. Det var derfor jeg opdagede den lige da jeg testede den nye køreplan, og det var derfor det holdt op med at ske for Aarhus til Odense, fordi der var gået en dag mere så jeg skulle scrolle længere tilbage for at komme til starten. Hvorimod Sælvig til Hou går så sjældent at den stadig var tæt på første afgang. Så det var slet ikke en nondeterministisk fejl, den var deterministisk men afhang af tidspunktet jeg testede.
Det var i sidste ende en ret nem fejl, det tog ikke meget mere end en times tid at finde og fixe. Fejl kan være meget mere langhårede dog.