Exceptions til middag

Jeg fikk en gang utlevert et "gjennomarbeidet" Java-rammeverk. Det var de som hadde laget det, som sa det.

Rammeverket var ment for remote collaboration og kom med hardkodede valg vi ikke trengte og ikke kunne overstyre. Da vi tok det opp, var svaret at dette hadde de undersøkt, og at rammeverket implementerte det som var best. For alle, åpenbart.

Det kunne vi leve med. Verre var det at min egen try-catch rundt kall inn i rammeverket aldri fanget noe. Ting feilet, men ingen unntak kom ut.

Kildekode fikk vi ikke, så jeg dekompilerte jar-filen og fant omtrent dette:

try {
    // ... noe som kan feile ...
} catch (Exception e) {
}

Unntaket ble fanget og kastet i søpla før det nådde meg. Ingen stack trace, ingen logglinje, ingenting å nøste i.

Jeg patchet klassen, pakket om jar-filen og sendte fiksen tilbake, basert på deres egen dekompilerte kode. De fikset det. De innrømmet aldri at det hadde vært en feil.

Lærdom

En tom catch er ikke feilhåndtering, det er feilskjuling. Den skjuler ikke bare feilen, den tar fra deg muligheten til å finne den.

Hvorfor var den tom? Neppe fordi noen mente feilen aldri kunne skje. Java har checked exceptions: enten fanger du dem, eller så deklarerer du dem med throws og gjør dem til en del av ditt eget API. En tom catch er den raskeste veien til at kompilatoren slutter å mase. Det er ikke overmot, det er "orker ikke". Og alternativet er ikke dyrt: pakk unntaket inn i en RuntimeException med originalen som cause, så slipper du å endre API-et, og feilen kommer likevel fram.

"Vi har undersøkt dette" er ikke et teknisk argument. Vis hva dere fant, og la meg overstyre det når behovene mine er andre enn deres.