---
id: 448c02f1efb1042bc9e1d256fcd2acad
author: Rabbit Princess
title: Varför Go väljer explicit felreturnering och panic-recover i stället för try-catch-undantag
description: Vi undersöker begränsningarna hos try-catch-strukturer, som överför ansvaret för undantagshantering längs anropsstacken, och beskriver Gos panic-recover-design, som är avgränsad till explicit error-hantering vid anropspunkten och till tillstånd som inte kan återställas.
language: sv
date: 2024-10-16T07:06:25.186989697Z
path: /blog/posts/why-doesn-t-go-have-try-catch-zeb312147
category: language
lang_canonical:
    ko: https://blog.naver.com/sjc02183/222927597790
---

Go stöder medvetet inte try-catch utan endast syntaxen panic-recover. Detta har väckt missnöje hos de många utvecklare som är vana vid felhantering med try-catch. Varför då inte inkludera try-catch? Anledningen är att try-catch har flera problem.

## try-catch-finally

Try-catch-satsen (try-catch) är en konstruktion för att hantera felsituationer och undantagssituationer som kan uppstå under programmets körning (runtime). Dessutom anger finally-satsen kod som alltid ska köras, oavsett om ett undantag har inträffat eller inte.

## Felhantering och ansvar

På 1980- och 1990-talet var felhanteringen mycket enkel. Felmeddelandena var endast "disketten är full", "ingen diskett i enheten" och "saknar skrivbehörighet för disketten", och utvecklarna under denna tid hanterade fel genom att kasta (throw) felet till en central felhanteringspunkt. I denna situation fungerade try-catch-satsen effektivt.

Med tiden har dock situationen förändrats. Affärslogiken blev mer komplex, databaser och transaktioner tillkom, och genom nätverket anropades otaliga API:er, vilket krävde tolkning av många requestmeddelanden. Till och med införandet av samtidighetsprogrammering gjorde att fel måste hanteras i andra trådar än huvudtråden.

Felen blev så komplexa att de inte längre kunde hanteras på ett enda ställe, och ingen enskild plats kunde ansvara för alla fel. Det var här som try-catch fick ett allvarligt problem.

## Try-catchs ansvarsöverföring

Try-catch innebär, kort sagt, att den del av programmet som orsakar felet överlåter ansvaret (efterarbetet) för felet till någon annan. Mottagaren kan vara catch-satsen, den överordnade metoden, eller någon ännu längre upp i anropskedjan, den överordnade metodens överordnade metod och så vidare. Med andra ord, i en värld där felhanteringen blir allt fler och mer komplex, är den metod try-catch valt just "någon kommer att ordna det". Betrakta koden nedan.

```java
try {
    data = readFile("hello.txt");
    structuredData = parseData(data);
    insertDBStatus(structuredData[1]);
    startHTTPServer(structuredData[2]);
} catch (Exception e) {
    e.printStackTrace();
}
```

Problemet med koden ovan är att det inte är tydligt vem som ansvarar för att hantera printStackTrace, och det går inte att avgöra i vilken kod felet uppstod. Ju fler logiksatser som finns i try-blocket, desto värre blir problemet. Ironiskt nog blev utvecklare, ju mer komplex utvecklingen blev, alltmer beroende av try-catch-satsen som överför ansvar. De slutade överväga felhantering, deras ansvarskänsla minskade, och till slut glömde de själva kärnan i felhantering och undantagshantering. Hur löste då Golang detta problem?

## Panic och recover

En av Go:s fördelar är att språket har flera mekanismer som, utan att leda utvecklaren på villospår, hjälper till att forma goda utvecklare. Panic och recover är ett exempel på detta.

Panic och recover liknar vid första anblick try-catch, men de skiljer sig åt i att de inte överför ansvaret till någon annan när ett problem uppstår. I Go ska felet vid panik hanteras på den plats där paniken uppstod, snarare än att värdet skickas vidare utåt. Detta ger utvecklaren ansvar för felhanteringen och uppmuntrar till en djupare reflektion över var, av vem och hur felet ska hanteras. Det är som att garantera användaren autonomi samtidigt som man lämnar utrymme för eftertanke.

Dessutom är valet av ordet panic mycket träffsäkert. Till skillnad från try-recover ger ordet panic-recover utvecklaren ett tydligt tryck om att den endast ska användas i uppenbara felsituationer och inte i undantagssituationer. Naturligt nog undviker utvecklaren då att överanvända recover och använder den endast där det är nödvändigt. Detta bidrar i hög grad till att skriva koncis kod i Go.