I en applikasjon finnes det bare typer feil:
- Applikasjonsfeil
- Systemfeil
- Programmeringsfeil
Applikasjonsfeil skyldes at funksjonelle forutsetninger ikke er tilfredsstilt. I praksis er dette gjerne ugyldig eller feilformatert input som for kort fødselsnummer, e-postadresse uten @, dobbeltføring av betaling eller en kunde som har utilstrekkelig bonusnivå for å utføre en handling. Applikasjonsfeil kan sies å være forventet og skal håndteres på lik linje med andre krav. Det kan være krevende å forutse alle slike feilsituasjoner. Erfaringsmessig har forretningsfolk god oversikt over de vanligste funksjonelle problemene, mens teknikere er flinke til å tenke på grenseverdier og inkonsistens. En iterativ tilnærming med teknikker som test-drevet utvikling, brukerhistorier og BDD vil avsløre de fleste applikasjonsfeilene. I utgangspunktet skal det ikke være nødvendig å feilrette og rulle ut en ny versjon av applikasjonen for denne typen feil. For å håndtere applikasjonsfeilene som allikevel slipper ut i produksjon er det viktig med hyppig utrulling slik at man kan fange opp disse etterhvert som man får praktisk erfaring med systemet.
Systemfeil skyldes feil i applikasjonens omgivelser eller infrastruktur. Typisk er dette en disk som går full, et nettverk som blir utilgjengelig eller en server blir overbelastet. Slike feil er også til en viss grad forventet; de opptrer sjelden, kan være vanskelig å forutse, men i praksis er det gjerne rimelig enkelt å teste slike feilsituasjoner. Ved systemfeil kan det gi mening å kjøre fail-over om mulig, alternativt vente en stund for deretter å prøve operasjonen på nytt; denne type feilhåndtering tilbys gjerne av meldingssystemer. Feilretting og ny utrulling skal ikke være nødvendig for denne feiltypen.
Programmeringsfeil skyldes at utviklere ikke har gjort jobben sin. De oppstår når applikasjonen ikke klarer å håndtere uventede hendelser på på robust vis. Typiske eksempler på dette (i en Java-applikasjon) er når systemet spyr ut feil av typen NullPointerException, NoSuchElementException og IndexOutOfBoundsException. Godt håndtverk med teknikker som TDD og automatisert testing, parprogrammering og kodegjennomgang er effektive tilnærminger for å minimere denne typen feil. Når en programmeringsfeil oppstår krever det en feilretting og påfølgende utrulling av ny versjon.
Tabellen under gir en oversikt over feiltypene og om de bør fanges og håndteres i applikasjonen, om det er mulig å vente litt og prøve operasjonen på nytt samt om den krever feilretting og utrulling av ny versjon:
| Type | Fanges og håndteres? | Prøve på nytt? | Feilretting og utrulling? |
|---|---|---|---|
| Applikasjonsfeil | Ja/Mulig | Nei | Nei |
| Systemfeil | Nei/Mulig | Ja | Nei |
| Programmeringsfeil | Nei | Nei | Ja |
Dårlig feilhåndtering er dessverre alt for utbredt i vår industri. Antall stacktrace i loggen er en indikator på hvilken kvalitet applikasjonen har; applikasjonsfeil og systemfeil skal være håndtert mens programmeringsfeil skal være luket ut i utviklingsprosessen. Et bevisst forhold til feiltyper og hvordan de bør håndteres er et godt utgangspunkt for å lykkes på dette området. Riktig feilhåndtering krever imidlertid målrettet innsats gjennom hele utviklingsløpet.
Pingback: Riktig feilhåndtering: Feilkategori og -hendelse – BEKK Open