Feilkategori vs. -hendelse

Når man feilsøker kan man skille mellom to ulike behov:

• Feilkategori beskriver hvilken feil som har oppstått. Den kategoriserer hendelser av samme type, og brukes for å forstå hva som har skjedd.
• Identifisering av feilhendelsen forteller hva som har skjedd til en bestemt tid i en spesifikk sammenheng. Typisk er dette nyttig for å finne ut hva som har skjedd når man feilsøker en bestemt feilsituasjon meldt av en bruker.

Feilkategorisering

Feilkategorisering har flere alternative tilnærminger:

• Hver feilkategori representeres med en egen Exception. Java SE APIet er et eksempel på denne tilnærmingen. Dette resulterer typisk i mange Exception-klasser  definert på ulike steder i pakkestrukturen. Tilnærmingen kan derfor kalles distribuert.
• Et fåtall sentrale Exception-klasser definerer feiltypene (gjerne Applikasjonsfeil, Systemfeil og Programmeringsfeil). For hver feiltype defineres en ID som feiltypen bærer med seg (typisk en Enum spesifisert i constructor). Denne tilnærmingen kan ses på som sentralisert.
• Kombinasjoner av disse, for eksempel et fåtall sentrale Exception-klasser med distribuerte subklasser.

Sentralisert feilhierarki

Uavhengig av tilnærming er hensikten å gjenkjenne feilen og forstå hvorfor den oppstår. En driftsperson vil kanskje lage en erfaringsbase for kjente feilkategorier. En utvikler som skal feilrette har også god nytte av god feilkategorisering for å finne årsaken.

Min erfaring er at applikasjoner lykkes best med en sentralisert tilnærming, der man definerer feilkategoriene som en felles Enum. Rammeverk (f.eks. Java SE API og Spring Framework) velger gjerne en distribuert tilnærming; ettersom dette ikke er applikasjoner har man ikke det samme behovet for sentral oversikt over feilkategoriene.

Enum Kategori { INGEN_PENGER, FEIL_ROLLE, UTESTENGT };
...
 
public class AbstractException() {
   public AbstractException(Kategori kategori, ...) {
      ...
   }
}

Kategorisereing av feil ved hjelp av Enum

Identifisering av feilhendelse

For å finne ut av en spesifikk feil ønsker man å identifisere den unike hendelsen som forårsaket feilen. Typisk er dette en situasjon der en bruker melder en feil eller når man feilsøker en hendelse som andre har rapportert tidligere. Å kunne identifisere denne ene feilen i en stor loggfil er gull verdt. Dette krever at hver enkelt feil blir logget med en unik ID.

En teknikk som fungerer bra nok i de fleste sammenhenger er å bruke tidspunktet feilen oppstår (i millisekunder) som ID. Denne IDen vises i feilsammenheng og skrives samtidig til feilloggen. Sannsynligheten for at to eller flere feil oppstår i samme millisekund er tilstede, men denne teknikken vil uansett begrense utvalget til et minimum. Funksjonaliteten for å lagre IDen implementeres i Exception-superklassen.

public class AbstractException() {
   private final long uid;
   public AbstractException(...) {
      uid = System.currentTimeMillis(); // skrives til loggen
   }
}

Eksempel på identifisering av Exception-instans med timestamp.

Oppsummering

God feilhåndtering forutsetter riktig kategorisering av feil i tillegg til støtte for å identifisere hver enkelt feilhendelse. Som alltid krever dette at man har et bevisst og målrettet forhold til feilhåndtering gjennom hele prosjektløpet. Det er fullt mulig å unngå at feilkategorisering og idendifisering av feilhendelse blir klattet på mot slutten av et prosjekt; å involvere driftpersoner som kravstillere på lik linje med annen funksjonalitet er en god start. God kontekstinformasjon i en feilsituasjon er også viktig, dette blir et eget tema i denne serien.