De ce Go nu are Try-Catch?

Go nu suportă în mod intenționat try-catch, ci doar sintaxa panic-recover. Acest lucru a stârnit resentimente din partea multor dezvoltatori familiarizați cu gestionarea erorilor prin try-catch. Atunci, care este motivul pentru care try-catch nu este inclus? Motivul este că try-catch are mai multe probleme.

try-catch-finally

Blocul try-catch este o sintaxă pentru gestionarea situațiilor de eroare și a excepțiilor care pot apărea în timpul execuției unui program (runtime). În plus, blocul finally conține codul care trebuie executat necondiționat, indiferent dacă a avut loc o excepție sau nu.

Gestionarea erorilor și responsabilitatea

În anii '80 și '90, gestionarea erorilor era foarte simplă. Mesajele de eroare erau doar 'Discheta este plină', 'Nu există o dischetă în unitate', 'Nu există permisiune de scriere pe dischetă' și, în acea perioadă, dezvoltatorii, atunci când apărea o eroare, o aruncau (throw) până la punctul de gestionare a erorilor pentru a fi tratată în mod centralizat. În această situație, sintaxa try-catch funcționa eficient.

Cu toate acestea, odată cu trecerea timpului, situația s-a schimbat. Logica de afaceri a devenit mai complexă, au apărut baze de date și tranzacții, a devenit necesară interpretarea a numeroase mesaje de solicitare prin apelarea a numeroase API-uri prin rețea și, chiar, odată cu apariția programării concurente, a devenit necesar să se gestioneze erorile în alte thread-uri decât cel principal.

Erorile au devenit atât de complexe încât nu mai puteau fi gestionate într-un singur loc, iar nimeni nu mai putea fi responsabil pentru toate erorile. Aici apare o problemă serioasă cu try-catch.

Delegarea responsabilității try-catch

Try-catch, într-un cuvânt, este o modalitate prin care entitatea care a provocat o eroare deleagă responsabilitatea (gestionarea ulterioară) pentru apariția erorii altcuiva. Această persoană căreia i se deleagă responsabilitatea poate fi blocul catch, metoda părinte a sa, părintele părintelui său, părintele părintelui părintelui său etc. Cu alte cuvinte, într-o lume în care gestionarea erorilor devine tot mai mare și mai complexă, metoda aleasă de try-catch este 'cineva se va ocupa de asta'. Să analizăm codul de mai jos.

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(); //tipărește stiva de apeluri
8}

Problema codului de mai sus este că nu este clar nici cine este responsabil pentru gestionarea printStackTrace, nici ce cod a provocat eroarea. Mai mult, cu cât mai multă logică apare în interiorul instrucțiunii try, cu atât problema devine mai gravă. Dar, în mod paradoxal, pe măsură ce dezvoltarea devine mai complexă, cu atât dezvoltatorii au devenit mai dependenți de blocul try-catch, care deleagă responsabilitatea, nu s-au mai gândit la gestionarea erorilor, conștiința responsabilității lor s-a diminuat și, în cele din urmă, au uitat de esența gestionării erorilor și a excepțiilor. Atunci, cum a rezolvat golang această problemă?

panic, recover

Unul dintre avantajele Go este că are mai multe sisteme pentru a transforma dezvoltatorii în dezvoltatori buni, în loc de a-i face să o ia pe căi greșite. panic - recover poate fi, de asemenea, dat ca exemplu.

Panic și recover nu par a avea diferențe față de try-catch la prima vedere, dar se diferențiază prin faptul că, atunci când apare o problemă, responsabilitatea nu este delegată către exterior. Când apare o panică în Go, în loc să se transmită valoarea către exterior, aceasta trebuie rezolvată în locul în care a avut loc panica. Acest lucru atribuie dezvoltatorului responsabilitatea gestionării erorilor și îl ghidează să se gândească mai profund la locul, cine și cum ar trebui să gestioneze eroarea respectivă. Se garantează autonomia utilizatorului, lăsând în același timp spațiu de reflecție.

În plus, alegerea cuvântului panic poate fi considerată și ea remarcabilă, deoarece, spre deosebire de try-recover, panic-recover îi impune dezvoltatorului, doar prin cuvinte, să folosească această sintaxă doar în situații clare de eroare, nu în situații de excepție. În mod natural, dezvoltatorul nu va abuza de recover și îl va folosi doar acolo unde este necesar. Acest lucru ajută foarte mult la scrierea unui cod concis în Go.