Strømmer, lesere og skrivere

Java skiller mellom byte-strømmer (InputStream/OutputStream) og tegn-strømmer (Reader/Writer). Tekst leses helst med Reader, men eksamensoppgavene tar ofte inn en InputStream fordi det gjør metoden lettere å teste. Du kobler dem sammen slik:

InputStream stroem = ...;
Reader leser = new InputStreamReader(stroem);
BufferedReader buffer = new BufferedReader(leser);   // gir readLine()

I praksis holder det ofte med Scanner, som kan ta både InputStream, Reader, File og String:

try (Scanner scanner = new Scanner(stroem)) {
    while (scanner.hasNextLine()) {
        String linje = scanner.nextLine();
        // behandle linja
    }
}

Ta inn en strøm, ikke et filnavn

Skriv lesFra(InputStream stroem) framfor lesFra(String filnavn). Da kan metoden testes med new ByteArrayInputStream("linje1\nlinje2".getBytes()) uten at det finnes noen fil, og den samme koden kan lese fra nett eller fra en ressurs i prosjektet. Ressurser hentes med getClass().getResourceAsStream("data.txt"). Dette er samme testbarhetsargument som når en klasse tar PrintStream som parameter i stedet for å skrive til System.out.

Parsing linje for linje

Et vanlig tekstformat er én post per linje med felt skilt av komma. Del opp med split og konverter feltene:

public void lesEmner(InputStream stroem) {
    emner.clear();                               // kallet skal erstatte det som var der
    try (Scanner scanner = new Scanner(stroem)) {
        while (scanner.hasNextLine()) {
            String[] felt = scanner.nextLine().split(",");
            String kode = felt[0].trim();
            double snitt = Double.parseDouble(felt[1].trim());
            Emne emne = finnEllerOpprett(kode);
            emne.setSnitt(snitt);
            for (int i = 2; i < felt.length; i++) {
                emne.leggTilForkrav(finnEllerOpprett(felt[i].trim()));
            }
        }
    }
}

Finn-eller-opprett-mønsteret

Det vanskeligste ved innlesing av objektstrukturer er at en linje kan referere til et objekt som først dukker opp lenger nede i fila. Løsningen er en privat hjelpemetode som enten finner det eksisterende objektet eller lager et tomt skall som fylles ut senere:

private Emne finnEllerOpprett(String kode) {
    Emne emne = getEmne(kode);
    if (emne != null) {
        return emne;
    }
    emne = new Emne(kode);      // tomt skall, snitt settes naar linja for emnet leses
    emner.add(emne);
    return emne;
}

Dermed blir strukturen riktig uansett rekkefølge, og du slipper å lese fila to ganger. Merk også at lesEmner tømmer samlingen først — oppgaveteksten sier ofte eksplisitt at et nytt kall skal erstatte det gamle innholdet.

Skriving og lagring

public void lagre(Writer skriver) throws IOException {
    try (PrintWriter ut = new PrintWriter(skriver)) {
        for (Emne emne : emner) {
            ut.print(emne.getKode() + "," + emne.getSnitt());
            for (Emne forkrav : emne.getForkrav()) {
                ut.print("," + forkrav.getKode());
            }
            ut.println();
        }
    }
}

Kravet er alltid at lagre og lese skal være inverse: leser du inn igjen det du nettopp skrev, skal du få en identisk objektstruktur. Test det ved å skrive til en StringWriter og lese tilbake med en StringReader.

Unntakshåndtering — og hvordan du begrunner valget

IOException er et checked unntak: kompilatoren tvinger deg til enten å fange det eller å deklarere throws IOException. Eksamen ber deg begrunne valget, og begrunnelsen skal handle om hvem som kan gjøre noe med feilen:

throws IOException når metoden er et bibliotek som ikke vet hva som er riktig reaksjon. Den som kalte metoden vet om den skal vise feilmelding, prøve en annen fil eller avbryte.
try/catch når metoden faktisk kan håndtere feilen — for eksempel returnere en tom samling når fila ikke finnes, fordi det bare betyr «ingen data lagret ennå».
Aldri tom catch-blokk. Skal du sluke unntaket, må du minst logge det eller pakke det i et IllegalStateException med e som årsak.

public Collection<Emne> lesEllerTom(InputStream stroem) {
    try {
        return les(stroem);
    } catch (IOException e) {
        return new ArrayList<>();       // ingen lagrede data er en gyldig tilstand
    }
}

try-with-resources

Alt som implementerer AutoCloseable bør åpnes i en try (...)-parentes. Da lukkes ressursen automatisk, også hvis det kastes unntak midt i blokka — i motsatt rekkefølge av åpningen. Uten dette lekker filhåndtak, og på Windows kan fila forbli låst. Merk at Scanner lukker den underliggende strømmen når den lukkes; skal strømmen brukes videre etterpå, må du la være å lukke scanneren.

Robusthet mot feil format

Oppgaveteksten sier ofte «du kan anta at alle linjer er på riktig format» — da skal du ikke bruke tid på validering. Står det derimot at metoden ikke skal utløse unntak ved feil format, må du fange NumberFormatException og ArrayIndexOutOfBoundsException per linje og hoppe over de dårlige linjene. Les kravet nøye; her mister mange poeng på å gjøre for mye eller for lite.

Studieguide: Filbehandling og I/O