Att leta buggar kan vara jobbigt, men om man inte vet om det här tipset så är det VÄLDIGT jobbigt.
Felhantering
Vanligtvis så har man ju felhantering (TRY/CATCH/FINALLY) i sina rutiner så att programmet hanterar alla fel som man tänkt kan inträffa i koden. Om man läser en fil så hanterar man att filen är låst eller borttagen och andra saker som vanligtvis inträffar när man läser filer.
Ofta så har man en generell felhantering Catch ex as Exception, eller först specifika catch:ar följt av en generell som sväljer allt man inte tänkt på. (Nu förespråkar jag inte att göra som i exemplet nedan utan det är som sagt bara ett exempel:
Exempel på generell try/catch
Try
Dim FileContent As String = IO.File.ReadAllText("c:\t.txt")
Catch ex As Exception
MsgBox("Det gick inte att läsa filen!")
End Try
I och med att man har lagt till try/catch på det här sättet så sväljs ju andra fel. I exemplet nedan så kommer man få index out of bound om filen inte innehåller några rader, detta fel sväljs dock av try/catch:en och samma felmeddelande visas oavsett fel:
Try
Dim FileContent As String = IO.File.ReadAllText("c:\t.txt")
Dim rows() As String = Split(FileContent)
Dim firstrow As String = rows(1)
Catch ex As Exception
MsgBox("Det gick inte att läsa filen!")
End Try
Det gör att du inte vet var det smällde, bara att nånstans i anropskedjan så smällde det och du hamnade i Catch-delen (som kan vara en helt annan klass i en helt annan fil än där felet inträffade. Om rutinen innehåller många rader kod så vet man ju inte i vilken rad det smäller för man hamnar i catch-delen.
Den svåra vägen
Här har jag sett att många utvecklare kör den svåra vägen, sätter breakpoints överallt i koden och steppar igenom programmet tills det smäller, letar sig tillbaka till sista raden innan det smällde och sedan sätter breakpoint där för att se vad det var som hände. Detta kan vara väldigt tidsödande om det är en invecklad kodbas.Speciellt om det är svårt att återskapa felet och det kanske bara inträffar vid vissa speciella förutsättningar.
Lösningen
Visual Studio har stöd för att lösa detta problem snabbt. Nånstans smäller det, du vet inte vart för felet sväljs av befintlig felhantering. Lösning: Tala om för debuggern att break:a ÄVEN fast du hanterar felet. Då stannar programmet och den raden som orsakade felet markeras i editorn direkt. Inget krångel med att steppa igenom kod med breakpoints osv.
Som standard så är debuggern inställd på att hamna i break-mode enbart på fel som du INTE hanterat med try/catch. Genom att välja menyn Debug och undermenyvalet Exceptions så får du upp en dialogruta som ser ut så här:
När du letar buggar så öppnar du helt enkelt bara upp den dialogrutan (går att göra även när programmet körs) och kryssar i att den ska break:a när ett CLR exception är kastat (thrown) och klickar på OK, alla fel som inträffar i din kod kommer nu att göra så att debuggern breakar och markerar raden som utförde felet, oavsett om du hanterar felet eller ej. I bilden nedan är kryssrutan markerad.
Happy bug hunting!
/Stefan