Waarom heeft Go geen Try-Catch?

Go ondersteunt opzettelijk geen try-catch, maar alleen de panic-recover syntaxis. Dit leidt tot ontevredenheid bij veel ontwikkelaars die bekend zijn met foutafhandeling met behulp van try-catch. Wat is dan de reden om geen try-catch toe te voegen? Dat komt omdat try-catch verschillende problemen heeft.

try-catch-finally

De try-catch instructie is een instructie voor het afhandelen van fouten en uitzonderingen die kunnen optreden tijdens de uitvoering van een programma (runtime). Bovendien wordt in de finally instructie code geplaatst die onvoorwaardelijk moet worden uitgevoerd, ongeacht of er een uitzondering is opgetreden.

Foutafhandeling en verantwoordelijkheid

In de jaren 80 en 90 was foutafhandeling zeer eenvoudig. Foutmeldingen waren slechts 'floppy disk vol', 'geen floppy disk in de drive' en 'geen schrijfrechten voor floppy disk', en ontwikkelaars in die tijd gooiden de fout tot aan het foutafhandelingspunt om het gezamenlijk af te handelen. In deze situatie werkte de try-catch instructie efficiënt.

Naarmate de tijd verstreek, veranderde de situatie echter. Bedrijfslogica werd complexer, databases en transacties ontstonden, talloze API's werden via het netwerk aangeroepen, talloze verzoekberichten moesten worden geïnterpreteerd en zelfs met de komst van concurrerende programmering moesten fouten in andere threads dan de main worden afgehandeld.

Fouten werden zo complex dat ze niet meer op één plaats konden worden afgehandeld en niemand kon alle fouten op één plaats op zich nemen. Hier ontstaat een ernstig probleem met try-catch.

Verantwoordelijkheidsoverdracht van try-catch

Try-catch is, in één woord, een manier voor de partij die de fout heeft veroorzaakt om de verantwoordelijkheid (opruiming) voor het optreden van de fout naar iemand anders te verschuiven. Het doel van de overdracht kan de catch instructie zijn, de bovenliggende methode, de bovenliggende methode van de bovenliggende methode, enz. Met andere woorden, in een wereld waar foutafhandeling talrijker en complexer wordt, is de door try-catch gekozen methode 'iemand zal het wel doen'. Kijk naar de onderstaande code.

1try {
2    data = readFile("hello.txt");
3    structuredData = parseData(data);
4    insertDBStatus(structuredData[1]);
5    startHTTPServer(structuredData[2]);
6} catch (Exception e) {
7    e.printStackTrace();
8}

Het probleem met de bovenstaande code is dat het onduidelijk is wie printStackTrace afhandelt en dat het onmogelijk is om te weten in welke code de fout is opgetreden. Het probleem wordt nog erger naarmate er meer logica in de try instructie komt. Paradoxaal genoeg raakten ontwikkelaars echter, naarmate de ontwikkeling complexer werd, verslaafd aan de try-catch instructie die verantwoordelijkheid overdraagt, maakten ze zich geen zorgen over foutafhandeling, vervaagde hun verantwoordelijkheidsgevoel en vergaten ze uiteindelijk de essentie van fout- en uitzonderingsafhandeling. Hoe heeft golang dit probleem opgelost?

panic, recover

Een van de voordelen van Go is dat er verschillende systemen zijn die voorkomen dat ontwikkelaars op het verkeerde spoor terechtkomen en hen helpen goede ontwikkelaars te worden. panic-recover is hier ook een voorbeeld van.

Panic en recover lijken in eerste instantie niet te verschillen van try-catch, maar ze verschillen in die zin dat ze de verantwoordelijkheid niet naar buiten afschuiven als er een probleem is opgetreden. Wanneer er in Go een panic optreedt, moet deze worden opgelost op de plaats waar de panic is opgetreden, in plaats van de waarde naar buiten te gooien. Dit geeft de ontwikkelaar de verantwoordelijkheid voor de foutafhandeling en leidt hen ertoe dieper na te denken over waar, wie en hoe de fout moet worden afgehandeld. Het garandeert de gebruiker autonomie, maar laat ook ruimte om na te denken.

De selectie van het woord panic is ook zeer uitstekend, want in tegenstelling tot try-recover dwingt panic-recover de ontwikkelaar door het woord alleen al om het alleen te gebruiken in duidelijke foutsituaties en niet in uitzonderingssituaties. Natuurlijk misbruiken ontwikkelaars recover niet en gebruiken ze het alleen waar nodig. Dit is een grote hulp bij het schrijven van beknopte code in Go.