Slik ser unntak ut på IN1010-eksamen

Unntak testes på fire av fem eksamenssett, og formen er alltid praktisk, aldri teoretisk. V2023 hadde en hel oppgave på 20 poeng: «Kun vogner og lokomotiv med samme sporvidde kan brukes sammen i et tog. Dersom sporvidden ikke er den samme, skal et unntak av typen FeilSporvidde kastes.» Deretter fulgte fire deloppgaver: skriv unntaksklassen, skriv en iterativ metode som sjekker hele lista, skriv en trygg innsettingsmetode, og skriv den rekursive varianten. Det er malen. Du skal kunne lage din egen unntaksklasse, kaste den fra en metode som går gjennom en datastruktur, og fange den der det er fornuftig.

Å lage sin egen unntaksklasse

Et unntak er en helt vanlig klasse som arver fra Exception eller RuntimeException. Sensorveiledningen for V2023 4a var kortfattet: «Her skal studenten vise at hen kan skrive en klasse som er en subklasse av Exception eller RuntimeException.» Ett poeng, tre linjer kode.

class FeilSporvidde extends Exception {
    FeilSporvidde(String melding) {
        super(melding);
    }
}

Konstruktøren sender meldingen videre med super(melding), og den kan senere leses ut med getMessage(). V2023-konte krevde nettopp dette: «Bruk en String-parameter til unntaksklassen for å skille de forskjellige unntakssituasjonene.» Én unntaksklasse med ulike meldinger er ofte bedre eksamenssvar enn fem nesten like klasser.

Checked mot unchecked

Dette skillet må sitte. Arver du fra Exception, er unntaket checked: hver metode som kan kaste det, må deklarere throws FeilSporvidde, og hver metode som kaller den, må enten fange det eller deklarere det videre. Kompilatoren håndhever dette. Arver du fra RuntimeException, er unntaket unchecked: ingen throws, ingen tvungen fangst. V2022 ba eksplisitt om «et egendefinert runtime-unntak med gjestens navn», altså den siste varianten.

class IngenReservasjon extends RuntimeException {
    IngenReservasjon(String navn) {
        super("Ingen reservasjon for " + navn);
    }
}

void tildelRom(String navn) {          // ingen throws nødvendig
    Reservasjon r = finnReservasjon(navn);
    if (r == null) throw new IngenReservasjon(navn);
    ...
}

Hele hierarkiet henger sammen slik: Throwable på toppen, med Error og Exception under. Error (som StackOverflowError og OutOfMemoryError) skal du aldri fange. Under Exception ligger RuntimeException med kjenninger som NullPointerException, ArrayIndexOutOfBoundsException, ClassCastException, ArithmeticException og NumberFormatException. Alt annet under Exception er checked, blant annet IOException og InterruptedException.

Kaste fra en gjennomløping

Den typiske eksamensoppgaven ser slik ut, og sensorveiledningen sier at «metoden må spesialbehandle tilfellet at listen er tom»:

void sjekkSporvidde() throws FeilSporvidde {
    if (forste == null) return;                   // tom liste: ingenting galt
    int normal = forste.hentSporvidde();
    for (Skinnegaende p = forste; p != null; p = p.neste) {
        if (p.hentSporvidde() != normal) {
            throw new FeilSporvidde("Feil sporvidde på " + p.hentId());
        }
    }
}

Når throw utføres, avbrytes metoden umiddelbart. Resten av løkka kjøres ikke, og kontrollen går til nærmeste omsluttende catch som passer — eventuelt oppover gjennom hele kallkjeden til main, og da avsluttes programmet med stakksporet.

Trygg innsetting

void leggTilSikker(Skinnegaende ny) throws FeilSporvidde {
    if (forste != null && ny.hentSporvidde() != forste.hentSporvidde()) {
        throw new FeilSporvidde("Kan ikke koble til " + ny.hentId());
    }
    leggTil(ny);                                  // gjenbruk metoden fra 3b
}

Legg merke til at unntaket kastes før objektet settes inn. Kaster du etterpå, står lista igjen i en ugyldig tilstand — og det er nettopp det unntaket skulle hindre.

try, catch og finally

try {
    tog.leggTilSikker(vogn);
    System.out.println("Vogn koblet til");
} catch (FeilSporvidde e) {
    System.out.println("Avvist: " + e.getMessage());
} finally {
    System.out.println("Forsøket er ferdig behandlet");
}

finally-blokka kjøres alltid — enten try gikk bra, kastet unntak, eller inneholdt en return. Det er derfor finally er stedet for opprydding: lukke filer, låse opp låser. Merk at hvis både try og finally inneholder return, vinner finally, og et unntak som var på vei ut, forsvinner stille. Det er en kjent felle, og grunnen til at man aldri skal skrive return i en finally-blokk.

Flere catch-blokker

try {
    int tall = Integer.parseInt(tekst);
    System.out.println(100 / tall);
} catch (NumberFormatException e) {
    System.out.println("Ikke et tall");
} catch (ArithmeticException e) {
    System.out.println("Deling på null");
} catch (Exception e) {
    System.out.println("Noe annet gikk galt");
}

Blokkene prøves ovenfra og ned, og den første som passer, brukes. Derfor må den mest spesifikke stå først. Setter du catch (Exception e) øverst, fanger den alt, og de under blir uoppnåelige — kompilatoren nekter faktisk å oversette det. Trenger du å behandle flere unntak likt, kan du slå dem sammen: catch (NumberFormatException | ArithmeticException e).

Unntak i iteratoren

V2023-konte krevde at next() kaster NoSuchElementException når det ikke er flere elementer igjen. Det er et unchecked unntak fra java.util, så det trenger ingen throws:

public Lederbil next() {
    if (peker == null) throw new NoSuchElementException();
    ...
}

Unntak fra en rekursiv metode

V2023 4d ba om den rekursive varianten av sporviddesjekken. Unntaket kastes like enkelt fra en rekursiv metode som fra en iterativ — det forplanter seg oppover gjennom alle de aktive kallene:

// i klassen Skinnegaende
void sjekkResten() throws FeilSporvidde {
    if (neste == null) return;                        // rekursjonsbunn
    if (neste.hentSporvidde() != sporvidde) {
        throw new FeilSporvidde("Ulik sporvidde ved " + neste.hentId());
    }
    neste.sjekkResten();                              // rekursivt kall
}

// i klassen Tog
void sjekkSporviddeR() throws FeilSporvidde {
    if (forste != null) forste.sjekkResten();
}

Detaljer verdt poeng

Fanger du et unntak og gjør ingenting (catch (Exception e) {}), skjuler du feilen. På eksamen er det bare akseptabelt for InterruptedException rundt Thread.sleep(), der oppgaveteksten selv viser den formen.
e.getMessage() gir teksten du sendte til super(...). e.printStackTrace() gir hele kallkjeden.
Kaster du et nytt unntak inne i en catch, kan du ta med det opprinnelige: throw new FeilSporvidde("...", e); hvis unntaksklassen har en konstruktør som tar en Throwable. Det kalles unntakskjeding, og årsaken hentes med getCause().
try-with-resources lukker ressurser automatisk: try (Scanner s = new Scanner(System.in)) { ... }. Praktisk, men sjelden påkrevd på eksamen.

Studieguide: Unntakshåndtering