Try catch i Node.js: slik håndterer du feil uten å krasje hele appen
Feil kommer alltid før eller siden i kode, spesielt i små prosjekter som vokser litt fortere enn planlagt. I Node.js kan dårlige feilvalg føre til at hele appen stopper, mens gode valg gir stabile tjenester som faktisk tåler virkeligheten.
I denne artikkelen ser vi på hvordantry/catchfungerer i Node.js, hva som skiller synkron og asynkron feil, og hvordan du kan bygge en ryddig strategi for feilhåndtering i egne prosjekter.
Hva try/catch egentlig gjør i Node.js
try/catchbrukes til å fange feil som oppstår inne i en blokk med kode. Når noe kaster en feil, hopper kjøringen direkte tilcatch-delen i stedet for å stoppe hele programmet.
Helt grunnleggende ser det slik ut i Node.js:
Eksempel:
try {
const result = JSON.parse('ikke gyldig json');
console.log('Dette kjører aldri', result);
} catch (error) {
console.error('Klarte ikke å parse JSON:', error.message);
}
console.log('Appen lever fortsatt');
Her villeJSON.parsenormalt kastet en feil som stopper programmet. Med try/catch får du kontroll, kan logge hva som skjedde, og la resten av appen kjøre videre.
Synkrone feil: når try/catch fungerer rett ut av boksen
Try/catch fungerer direkte påsynkron kode, altså kode som kjører linje for linje uten å vente på noe eksternt som database eller nettverk. Hvis en funksjon kaster en feil medthrow, kan du ta den med try/catch.
Eksempel på synkron funksjon som kan feile:
function divide(a, b) {
if (b === 0) {
throw new Error('Kan ikke dele på null');
}
return a / b;
}
try {
const value = divide(10, 0);
console.log('Resultat:', value);
} catch (error) {
console.error('Feil ved deling:', error.message);
}
Poenget her er at du bevisst kaster en feil når noe er galt, i stedet for å la programmet gå videre med ubrukelige verdier somNaNellerundefined.
Den store fellen: asynkrone feil og try/catch
I Node.js er mye kodeasynkron: databasekall, filoperasjoner, HTTP-forespørsler og tidtakere. Her fungerer ikke try/catch på samme måte som for synkron kode, og dette er en vanlig kilde til misforståelser.
Se på dette eksempelet med en tidsforsinkelse:
try {
setTimeout(() => {
throw new Error('Noe gikk galt inni setTimeout');
}, 1000);
} catch (error) {
console.error('Blir dette fanget?', error.message);
}
Her vil ikke feilen bli fanget av catch-blokken. På det tidspunktet feilen kastes, er try/catch-blokken allerede ferdig. Resultatet kan være at Node-prosessen krasjer hvis du ikke har en annen strategi.
Try/catch med async/await og Promises
Hvis du brukerasync/await, kan du igjen bruke try/catch rundt asynkron kode, så lenge du venter på Promise medawait. Feilen blir da kastet inn i samme kallestakk som try/catch befinner seg i.
Eksempel med async/await:
function delayFail() {
return new Promise((_, reject) => {
setTimeout(() => {
reject(new Error('Noe feilet etter venting'));
}, 1000);
});
}
async function run() {
try {
const result = await delayFail();
console.log('Kommer aldri hit:', result);
} catch (error) {
console.error('Fanget asynkron feil:', error.message);
}
}
run();
Nøkkelen er at duventerpå Promise med await. Hvis du glemmer await og bare kaller funksjonen, vil ikke try/catch fange feilen.
Vanlige feilgrep med try/catch i Node.js
Noen mønstre går igjen når man er ny til feilhåndtering i Node.js. Hvis du kjenner dem igjen, er det enklere å unngå dem.
- Å anta at try/catch fanger alt: Det gjelder bare for kode som faktisk kjøres inni try-blokken, og for async/await må du huske await.
- Å sluke feil i catch: Mange skriver bare
catch (e) {}eller bare logger litt. Da mister du informasjon som kan være kritisk senere. - Å legge hele appen i én stor try/catch: Dette gjør koden uoversiktlig og skjuler hvor feilen egentlig oppstår.
- Å kaste generelle strenger: Bruk
new Error()med en tydelig melding i stedet for bare en tekststreng.
En enkel strategi for ryddig feilhåndtering
For små og mellomstore Node-prosjekter kan du komme langt med noen enkle vaner. De gir deg oversikt, og gjør det enklere å feilsøke når noe svikter i produksjon.
- Valider input tidlig: Sjekk verdier før du gjør kostbare eller farlige operasjoner, og kast feilen der input først kommer inn.
- Pakk risikofylt kode: Bruk try/catch rundt konkrete operasjoner som filtilgang, parsing eller eksterne API-kall, ikke rundt «alt».
- Berik feilen: Legg på nyttig kontekst før du logger den, for eksempel hvilken filbane, hvilket ID-nummer eller hvilket tredjeparts-API som feilet.
- Ha ett sted som logger: I web- eller API-prosjekter er det nyttig med en felles feilhåndterer som logger konsistent før svar sendes til klient.
Try/catch i en enkel HTTP-tjener
La oss se på et lite, men realistisk eksempel i en HTTP-tjener der du vil unngå at én dårlig forespørsel tar ned hele prosessen. Vi bruker innebygdhttp-modul.
const http = require('http');
function parseNumber(value) {
const num = Number(value);
if (Number.isNaN(num)) {
throw new Error('Ugyldig tall: ' + value);
}
return num;
}
const server = http.createServer((req, res) => {
try {
const url = new URL(req.url, 'http://localhost');
const a = parseNumber(url.searchParams.get('a'));
const b = parseNumber(url.searchParams.get('b'));
const result = a + b;
res.writeHead(200, { 'Content-Type': 'application/json' });
res.end(JSON.stringify({ result }));
} catch (error) {
console.error('Feil i forespørsel:', error.message);
res.writeHead(400, { 'Content-Type': 'application/json' });
res.end(JSON.stringify({ error: 'Ugyldig input' }));
}
});
server.listen(3000, () => {
console.log('Lytter på http://localhost:3000');
});
Her bruker vi try/catch rundt selve forespørselshåndteringen. Hvis noe går galt i parsing eller beregning, returnerer vi en feilmelding til klienten i stedet for at hele tjeneren dør.
Når bør du la appen krasje likevel
Noen feil er så alvorlige at det kan være tryggere å la prosessen stoppe enn å prøve å fortsette. Typiske eksempler er når konfigurasjon mangler, tilkobling til databasen feiler ved oppstart, eller når du oppdager korrupte data i kritiske systemer.
Forskjellen er om feilen erforventet(dårlig input, nettverksproblem, timeout) ellerkritisk(programmet er i en tilstand du ikke stoler på). Forventede feil bør håndteres og logges, kritiske feil kan du la stanse prosessen, gjerne med tydelig logging så problemet kan løses.
Oppsummering: bygg vanen tidlig
God feilhåndtering i Node.js handler ikke om å fange absolutt alt, men om å fange feil på riktige steder, med riktig mengde informasjon og uten å gjøre koden uleselig. Bruk try/catch bevisst, spesielt sammen med async/await, og bestem deg for hvilke feil som skal håndteres og hvilke som bør stoppe prosessen.
Hvis du tidlig lager deg små mønstre for hvordan feil skal logges og håndteres, blir det mye enklere å skalere både prosjektet og egen forståelse når appen vokser.
0 kommentarer