4.2 «Finn feilen» og konkret moteksempel

En feil i selve skrivemåten: glemt kolon etter if, ulike antall parenteser, feil innrykk.

Python nekter å kjøre programmet i det hele tatt, og sier hvilken linje den stoppet på. Meldingen heter SyntaxError eller IndentationError.

Dette er den greieste feilen som finnes: du får vite hvor den er før noe har skjedd. På eksamen skriver du på papir eller i et enkelt tekstfelt uten hjelp, så her hjelper bare øvelse — kolon etter if, for, while og def, og fire mellomrom som innrykk.

Programmet starter, men stopper underveis. KeyError på en nøkkel som ikke finnes, IndexError på en plass utenfor lista, ZeroDivisionError på en tom samling, TypeError når du prøver å skjøte en tekst og et tall.

Feilmeldingens siste linje sier hva som gikk galt, og linjene over sier hvor.
Det er derfor du alltid leser nedenfra og opp.

Kjøretidsfeil er lette å oppdage så snart programmet kjøres — men på en hjelpemiddelfri eksamen kjører ingenting. Derfor er kanttilfellene noe du må prøve i hodet, ikke i maskinen.

Programmet kjører uten en eneste feilmelding, og gir feil svar.

Dette er sjanger I. Det er den vanskeligste feiltypen, fordi ingenting varsler deg: koden ser rimelig ut, den gir et resultat, og resultatet er galt.

De logiske feilene i faget er påfallende få og faste: en test som ikke slår til ved likhet, en return som står inne i løkka i stedet for etter, en teller som aldri ble initialisert, en løkkegrense som er én for stor eller liten, og en
«ikke funnet»-verdi som kolliderer med ekte data.

Fem mønstre — og du finner dem alle ved å spore koden på kritiske inndata.

Formen er alltid den samme:

«storst(4, 4, 4) gir None, men skulle gitt 4.»

Tre deler: kallet, svaret funksjonen faktisk gir, og svaret den skulle gitt. Alle tre må være med.

En forklaring i ord — «funksjonen håndterer ikke like verdier» — er ikke et moteksempel. Den kan gjerne stå i tillegg, som en setning etterpå. Men kallet er det sensor krysser av for.

De fem tilfellene du alltid prøver først, fordi det er der koden ryker:

1. Tom samling — [], {}, "". Løkker tåler den; indeksering og divisjon
gjør det ikke.
2. Ett element — avslører løkker som forutsetter minst to, for eksempel når
man sammenligner naboer.
3. Like verdier — avslører tester som bruker > der >= trengs.
4. Ingen treff — avslører manglende «ikke funnet»-håndtering.
5. En verdi på grensen — avslører av-med-én og kantfeil.

Lista er kort nok til å huskes, og den dekker praktisk talt alle sjanger
I-oppgavene i arkivet. Bruk den også på din egen kode i Oppgave 3 og 4.

En test som bruker > eller < der oppgaven mener «minst» eller «høyst».

Kjennetegnet er at funksjonen svarer riktig på alt unntatt verdier som ligger
nøyaktig på grensen. En aldersgrense på 18 som bruker alder > 18, utelukker
alle 18-åringer.

Moteksempelet skriver seg selv: bruk grenseverdien. Og les oppgaveteksten nøye — «over», «minst», «fra og med» og «under» betyr fire ulike ting.

Begge svarene står inne i løkka, så det første elementet avgjør alt.

Kjennetegnet er lett å se: return True og return False i samme løkkekropp, ofte med if/else. Det svaret som krever at du har sett alle elementene, hører etter løkka.

Moteksempelet må ha et første element som gir «feil» svar — ellers svarer den gale funksjonen tilfeldigvis riktig.

Dette er feilkode #7, og den er den mest dokumenterte enkeltfeilen i fagets løsningsforslag.

En teller eller en samling som brukes før den er opprettet.

To varianter. antall = antall + 1 uten antall = 0 før løkka gir NameError.
Og d[k] = d[k] + 1 uten if k not in d: d[k] = 0 gir KeyError — det er feilkode #14.

Kjennetegnet er at feilen slår til på første runde med data, men ikke på tom inndata. En funksjon som virker perfekt på den tomme lista og krasjer på alt annet, har nesten alltid denne feilen.

En løkkegrense som er én for stor eller én for liten.

De tre variantene du møter: range(len(liste)) når koden inni bruker
liste[i + 1] — da ryker siste runde. range(1, len(liste)) når du egentlig ville hatt med det første elementet. Og liste[len(liste)], som aldri finnes.

Kjennetegnet er at funksjonen enten krasjer med IndexError på siste element, eller stille hopper over ett element i hver ende.

Moteksempelet er en kort liste — to eller tre elementer. Da er én for mye eller for lite lett å se. Dette er feilkode #5 og #6.

En «ikke funnet»-verdi som også kan være ekte data.

-1 for «ikke funnet» er trygt når svaret er en plass i en liste, siden en plass aldri er negativ. Det er ikke trygt når svaret er en temperatur, en saldo, en høydeforskjell eller et hvilket som helst tall som kan være negativt.

0 er enda farligere: null er gyldig i nesten alle sammenhenger.

None er det trygge valget, fordi det aldri kan forveksles med et tall. Det
er derfor finn-beste-mønsteret i boka starter med beste = None. Dette er feilkode #10.

Formen er: én kodesnutt, fire påstander, og beskjed om å krysse av for alle
som er riktige.

To ting skiller den fra fritekstvarianten. Det ene er at noen av påstandene er sanne — det er ikke gitt at koden er feil i det hele tatt, og en påstand av typen «funksjonen virker som beskrevet» kan godt være riktig.

Det andre er at blankt er feil. Er du usikker, krysser du av likevel — det koster ingenting å gjette, og et blankt felt gir garantert null.

Metoden er å prøve hver påstand mot ett konkret kall, akkurat som når du leter etter et moteksempel.

Den eneste linja du trenger fra en feilmelding. Den har formen
FeilType: forklaring, for eksempel KeyError: 'plast'.

Linjene over sier hvor feilen skjedde, nedenfra og opp: den nederste av dem er linja i din egen kode.

Skal du gjengi en feilmelding i en besvarelse, skriver du siste linje ordrett — ikke oversatt til norsk, og ikke omskrevet. Det er den formen sensor kjenner igjen.

En feil som verken stopper programmet eller gir en melding — den gir bare feil svar.

Alle de fem faste feilene i dette kapitlet er stumme i minst ett tilfelle: for tidlig return svarer alltid noe, likhetsfella svarer riktig på alt unntatt grenseverdien, og sentinel-kollisjonen ser helt normal ut til dataene blir negative.

Det er derfor sporing på kritiske inndata er den eneste metoden som virker. Du kan ikke vente på at noe skal si fra.

Et moteksempel som ikke avslører feilen, er verdiløst — og det er lettere å lage enn man skulle tro.

En finn-beste-funksjon som glemmer å oppdatere beste_antall, svarer riktig når den største verdien står sist. En «alle»-funksjon med begge return inne i løkka, svarer riktig når det første elementet gir riktig svar.

Kontrollen tar ti sekunder: spor din egen kandidat i hodet, og se at svaret faktisk blir galt. Blir det riktig, velg andre data.

Rettelsen skal være minst mulig — én linje flyttet, ett tegn byttet, to linjer satt inn.

Unntaket er når feilen kommer av at studenten har valgt feil mønster. Da er den beste rettelsen å bytte hele mønsteret, slik storst ble skrevet om til finn-beste. Skriv i så fall én setning om hvorfor.

Ikke gjør begge deler samtidig. Å rette feilen og samtidig bytte variabelnavn og struktur gjør det vanskelig for sensor å se hva du mente — og uttellingen følger det sensor kan se.

Malen du sammenligner den innleverte koden med:

def alle_positive(tallene):
    for t in tallene:
        if t <= 0:
            return False return True

print(alle_positive([3, 5]), alle_positive([3, -1]))

Utskrift:

True False

Ett return inne i løkka, ett etter. Ser du to inne i samme løkke, er det feilkode #7 — hver gang.

Speilbildet gjelder for «finnes det noen»: return True inne, return False etter.

Den enkleste kontrollen som finnes for finn-beste-mønsteret: teller if-blokken like mange variabler som du satte før løkka?

To startverdier før løkka — beste og beste_antall — krever to oppdateringer inne i if-en. Én av hver er den vanligste feilen i hele sjangeren.

Kontrollen tar fem sekunder, og den virker på din egen kode like godt som på andres. Bruk den hver gang du har skrevet en finn-beste-løkke i Oppgave 3 eller 4.

Sentinel-verdien -1 for «ikke funnet» er trygg når svaret er en plass i en liste, fordi en plass aldri kan være negativ.

Den er utrygg for alt annet: temperaturer, saldoer, endringer og differanser kan alle være negative, og da kolliderer de to betydningene.

0 er aldri trygt, fordi null er gyldig i nesten enhver sammenheng.

Er du i tvil, bruk None. Det kan aldri forveksles med et tall, og det er grunnen til at boka bruker det i finn-beste-mønsteret.