Pourquoi Go n'a-t-il pas de Try-Catch ?

Go ne prend pas intentionnellement en charge try-catch, mais prend uniquement en charge la syntaxe panic-recover. Cela suscite le mécontentement de nombreux développeurs habitués à la gestion des erreurs à l'aide de try-catch. Alors, pourquoi ne pas inclure try-catch ? C’est parce que try-catch pose plusieurs problèmes.

try-catch-finally

La clause try-catch est une syntaxe permettant de traiter les situations d'erreur et les exceptions qui peuvent survenir pendant l'exécution d'un programme (exécution). De plus, la clause finally spécifie le code qui doit être exécuté inconditionnellement, que des exceptions se produisent ou non.

Gestion des erreurs et responsabilité

Dans les années 80 et 90, la gestion des erreurs était très simple. Les messages d'erreur se limitaient à « disquette pleine », « pas de disquette dans le lecteur » et « pas d'autorisation d'écriture sur la disquette ». Durant cette période, les développeurs, en cas d’erreur, lançaient cette erreur jusqu’au point de gestion des erreurs pour la traiter de manière uniformisée. Dans cette situation, la clause try-catch fonctionnait efficacement.

Cependant, avec le temps, la situation a changé. La logique métier est devenue plus complexe, les bases de données et les transactions ont fait leur apparition, et d’innombrables messages de requêtes ont dû être interprétés en appelant de nombreuses API via le réseau. En outre, avec l’avènement de la programmation simultanée, les erreurs ont dû être traitées dans des threads autres que le thread principal.

Les erreurs sont devenues trop complexes pour être traitées en un seul endroit, et il est devenu impossible pour un seul endroit d’être responsable de toutes les erreurs. C’est là qu’un problème grave survient avec try-catch.

Transfert de responsabilité de try-catch

En un mot, try-catch est une méthode par laquelle l'entité qui a provoqué une erreur transfère la responsabilité (post-traitement) de la survenance de l'erreur à quelqu'un d'autre. La cible de ce transfert peut être une clause catch, sa méthode parent, le parent du parent, le parent du parent du parent... qui que ce soit. En d'autres termes, dans un monde où la gestion des erreurs devient de plus en plus nombreuse et complexe, la méthode choisie par try-catch est « quelqu'un s'en chargera ». Regardons le code ci-dessous.

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}

Le problème avec le code ci-dessus est qu’il n’est pas clair qui est responsable du traitement de printStackTrace, ni quel code a provoqué l’erreur. De plus, plus il y a de logique dans l’instruction try, plus le problème est grave. Paradoxalement, cependant, à mesure que le développement devenait plus complexe, les développeurs sont devenus accros à la clause try-catch qui transfère la responsabilité, ont cessé de s’inquiéter de la gestion des erreurs, ont perdu le sens de la responsabilité et ont fini par oublier l’essence même de la gestion des erreurs et des exceptions. Alors, comment golang a-t-il résolu ce problème ?

panic, recover

L’un des avantages de Go est qu’il existe plusieurs systèmes conçus pour faire de vous un bon développeur, sans vous entraîner sur la mauvaise voie. panic - recover en est un exemple.

Panic et recover peuvent sembler ne pas être différents de try-catch à première vue, mais ils sont différents en ce qu’ils ne délèguent pas la responsabilité vers l’extérieur lorsqu’un problème survient. Lorsque panic se produit dans go, plutôt que de renvoyer la valeur vers l’extérieur, elle doit être résolue à l’endroit où panic s’est produite. Cela impose aux développeurs la responsabilité de la gestion des erreurs, en les incitant à réfléchir plus en profondeur à l’endroit où, qui et comment traiter l’erreur. Cela garantit l’autonomie des utilisateurs tout en laissant place à la réflexion.

De plus, la sélection du mot panic est également très excellente. Contrairement à try-recover, panic-recover impose aux développeurs, par le mot lui-même, qu’il ne doit être utilisé que dans des situations d’erreur claires et non dans des situations d’exception. Naturellement, les développeurs n’abusent pas de recover et ne l’utilisent que là où cela est nécessaire. Cela contribue grandement à écrire un code concis dans go.