När man börjar programmera så märker man snart att mycket tid går åt till att hitta fel i koden man skriver. Detta är dock inget som är enbart nybörjare "förunnat", utan något som du kommer att syssla med så länge du programmerar. Skillanden är bara att mer erfarna programmerare blir bättre på att hitta felen, men å andra sidan skriver de mer komplicerad kod, vilket gör att det blir svårare att hitta felen... så det jämnar ut sig. :)
Här kommer några tips om hur man enklare hittar felen i koden:
Visa felmeddelanden
Internet Explorer är som standard inställt att inte visa ASP-felmeddelanden, istället visas en generell informationssida. Anledningen till att webbläsaren är inställt på det viset är att en vanlig användare är mer hjälpt av det som står på informationssidan än av serverns felmeddelande. Vi programmerare är dock mer hjälpta av vad servern har att säga om felet.
Gå in i avancerade inställningar i webbläsaren (Verktyg > Internetinställningar > Avancerat). Leta upp raden med "Visa egna http-felmeddelanden" och se till att den inte är förbockad.
Gömda felmeddelanden
Ibland händer det att man inte ser felmeddelandet, utan en del av sidan bara saknas. Då ska du plocka fram html-koden för sidan (Visa > Källa) och se om det står ett felmeddelande längst ned i den. Ifall felmeddelandet skrivs ut efter vissa html-taggar så syns de nämligen inte på sidan.
Att förstå felmeddelandet
Att tyda felmeddelanden är inte alltid det lättaste, ofta får man reda på följderna av ett fel snarare än orsaken. Ifall man till exempel anger fel sökväg till en Access-databas så får man det kryptiska felmeddelandet att det inte gick att öppna en viss registernyckel. Efter ett tag lär man sig att förstå orsaken till de flesta felmeddelanden man får.
Vissa saker kan man dock nästan alltid läsa ut ifrån felmeddelanden:
1. Varifrån meddelandet kommer.
Ifall meddelandet kommer ifrån "VBScript compilation" så kan inte VBScript-motorn kompilera koden, datorn förstår helt enkelt inte programkoden.
Ifall meddelandet kommer ifrån "VBScript runtime" så är det något som blev fel medan koden kördes.
Ifall meddelandet kommer ifrån databasen (vanligen Access, JET, ADO eller ODBC) så blev det fel när man försökte öppna databasen, eller när en databasfråga kördes.
2. Var i koden det blev fel.
Felmeddelandet åtföljs oftast av ett radnummer. Ofta är dock själva felet inte på just den raden, utan på någon av raderna innan. Vanligt är att någon av variablerna som används på raden innehåller ett felaktigt värde. Då får man titta längre upp i koden hur variablerna som används får sina värden.
Skriv ut lämpliga värden
Många fel beror på att man får felaktiga värden i variabler eller liknande. För att se vad som ligger i variablerna så får man skriva ut värdena på webbsidan så att man ser dem. När man får ett felmeddelande så visas inte sidan, så man måste dessutom avbryta körningen av koden innan felet uppstår för att kunna se värdena man skriver ut.
Ifall du till exempel satt ihop en databasfråga i variabeln strSQL, och du får ett felmeddelande när du kör frågan mot databasen, så är det en bra början att skriva ut strSQL så att man ser hur databasfrågan blev egentligen. Det gör du så här:
Response.Write strSQL
Response.End
Den andra raden är för att stoppa programkörningen. (Egentligen ska man stänga eventuella recordset och databaskopplingar innan man stoppar koden så här, men eftersom det är testkod som bara ska köras en enda gång, så kan man fuska med det.)
Ifall värdena ser rätt ut, men det uppenbarligen måste vara något fel på dem ändå, så kan du ta reda på vad det är för datatyp på variablerna. Ifall det är fel datatyp på en variabel så kan det nämligen ställa till problem. Om det till exempel ligger ett tal i en variabel, men datatypen är sträng, så blir det fel ifall man försöker behandla variabeln som om den innehöll ett tal. Så här skriver du ut datatypen för en variabel:
Response.Write TypeName(variabeln)
Response.End
Kolla om kod körs
Ibland får man inget felmeddelande, utan koden gör helt enkelt inte som man förväntar sig. Ifall du till exempel har en If-sats som gör att en viss del av koden körs under vissa förutsättningar, och koden inte verkar köras, så kan det vara lämpligt att kolla ifall koden verkligen körs eller inte. Exempel:
If Request.Querystring("acion")="" Then
Response.Write "tjolahopp"
Response.End
... koden som du vill kolla ifall den körs eller inte
End If
Kommentera ut kod
Ibland är man hjälpt av att testa vad som händer när en viss del av koden inte körs, till exempel om man vet att viss kod inte borde köras, men verkar köras ändå. Då kan man förvandla kodraderna till kommentarer genom att sätta en apostrof först på raden.
Här är ett exempel där lngPage ibland får fel värde, och hur man testar ifall det är en viss rad som orsakar det. (Själva felet är att både lngPage och lngPages innehåller strängar, och värdet "5" är faktiskt mer än "21".) Genom att kommentera ut den tredje raden så försvinner problemet, och man vet att det är koden på den raden som gör att värdet blir fel.
lngPage = Request.Querystring("page")
lngPages = Request.Querystring("pages")
'If lngPage > lngPages Then lngPage = lngPages
Söka fel utan radnummer
Ibland får man inget radnummer i felmeddelandet, och ingen annan ledning av meddelandet var det kan vara fel. Då får man helt enkelt testa sig fram var felet uppstår genom att lägga in en Response.End någonstans i koden. Ifall felmeddelandet kommer så uppstår felet innan den rad där man lade in stoppet, annars uppstår felet efter den raden. Genom att flytta stoppet kan man efter några försök isolera en eller några få rader där felet uppstår.
Tänk som datorn
För att förstå varför en del fel uppstår så får man gå igenom koden och tänka igenom vad som egentligen händer när datorn kör koden. Vilka värden som används, vilka variabler som ändras och hur flödet går igenom programkoden. Ju mer du förstår av programkoden, desto större chans har du att hitta felen.
Datorn gör precis det du skrivit i koden, och när du och datorn har olika åsikter om vad som ska hända, så är det tyvärr datorn som har tolkningsföreträde...
Det var väl det mesta... Lycka till med felsökningen nu.
Göran Andersson