---
id: 448c02f1efb1042bc9e1d256fcd2acad
author: Rabbit Princess
title: Miért választotta a Go a kivételdobás (try-catch) helyett az explicit hibaértékek visszaadását és a panic-recover mechanizmust
description: Ez a szöveg a try-catch szerkezet korlátait vizsgálja, amely a hívási verem mentén hárítja el a kivételkezelés felelősségét, és ismerteti a Go panic-recover tervezését, amely a hívási helyen történő explicit error-kezelésre és kizárólag a helyreállíthatatlan állapotokra korlátozódik.
language: hu
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
---

A Go szándékosan nem támogatja a try-catch szerkezetet, hanem kizárólag a panic-recover szintaxist biztosítja. Ez számos, a try-catch alapú hibakezeléshez szokott fejlesztő elégedetlenségét váltotta ki. Miért nem került bele a try-catch? Azért, mert a try-catch számos problémát hordoz magában.

## try-catch-finally

A try-catch (trájkecs) szerkezet a program futása közben (futásidőben) felmerülő hibás és kivételes helyzetek kezelésére szolgáló konstrukció. A finally szerkezet pedig olyan kódot tartalmaz, amelynek a kivétel bekövetkezésétől függetlenül feltétlenül le kell futnia.

## Hibakezelés és felelősség

A 80-as és 90-es években a hibakezelés rendkívül egyszerű volt. A hibaüzenetek csupán az „elfogyott a hajlékonylemez-terület", a „nincs hajlékonylemez a meghajtóban" és a „nincs írási jogosultság a hajlékonylemezhez" üzenetekre korlátozódtak, a korabeli fejlesztők pedig hiba esetén a hibát a hibakezelési pontig dobták (throw), és ott, egységesített módon kezelték. Ilyen körülmények között a try-catch szerkezet hatékonyan működött.

Az idő múlásával azonban a helyzet megváltozott. Az üzleti logika egyre összetettebbé vált, megjelentek az adatbázisok és a tranzakciók, számos API-t kellett hálózaton keresztül hívni, és rengeteg kérésüzenetet kellett értelmezni, sőt a párhuzamos programozás megjelenésével a hibákat a főszálon kívül, más szálakban is kezelni kellett.

A hibák már nem kezelhetők egyetlen helyen, és egyetlen pont sem vállalhatja felelősséget minden hibáért. Ebben a helyzetben a try-catch komoly problémává válik.

## A try-catch felelősséghárítása

A try-catch lényegében azt jelenti, hogy a hibát előidéző egység a hibáért viselt felelősséget (az utólagos teendőket) másra hárítja. Ez a másik fél lehet a catch blokk, a szülő metódus, vagy a szülő szülőjének szülője, szülőjének... valakije. Más szóval, egy olyan világban, ahol a hibakezelés egyre több és egyre bonyolultabb, a try-catch által választott megoldás nem más, mint a „majd valaki megoldja" elv. Nézzük az alábbi kódot.

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

A fenti kód problémája, hogy nem egyértelmű, ki felelős a printStackTrace kezeléséért, és az sem derül ki, melyik kódsorban keletkezett a hiba. Sőt, minél több logika kerül a try utasításba, annál súlyosabbá válik a probléma. Paradox módon azonban minél bonyolultabbá vált a fejlesztés, a fejlesztők annál inkább rászoktak a felelősséget áthárító try-catch szerkezetre, nem gondolkodtak a hibakezelésen, felelősségtudatuk meggyengült, és végül elfelejtették a hiba- és kivételkezelés lényegét. Hogyan oldotta meg ezt a problémát a Golang?

## Panic, recover

A Go egyik előnye, hogy számos olyan rendszert tartalmaz, amelyek nem terelik a fejlesztőt rossz irányba, hanem jó fejlesztővé formálják. A panic-recover is ennek egyik példája.

A panic és a recover első pillantásra nem különbözik a try-catch szerkezettől, de abban különbözik, hogy problémát okozva nem hárítja a felelősséget külső helyre. Go-ban panik esetén a hibaértéket nem a külvilág felé továbbítják, hanem a panik helyén kell megoldani. Ez a fejlesztőre helyezi a hibakezelés felelősségét, és arra készteti, hogy alaposabban átgondolja, hol, ki és hogyan kezelje az adott hibát. Ez a megközelítés a felhasználónak autonómiát biztosít, miközben teret hagy a gondolkodásnak.

Emellett a panic elnevezés is rendkívül találó, hiszen a try-recover párral ellentétben a panic-recover szó önmagában is arra készteti a fejlesztőt, hogy csak egyértelmű hibahelyzetekben, és ne kivételes helyzetekben használja. Ennek következtében a fejlesztő nem él vissza a recover használatával, hanem csak ott alkalmazza, ahol valóban szükséges. Ez nagy segítséget nyújt a tömör kód írásában Go-ban.