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

Go ne prend délibérément pas en charge le try-catch et ne prend en charge que la syntaxe panic-recover. Cela suscite le mécontentement de nombreux développeurs habitués à la gestion des erreurs via try-catch. Alors, pourquoi ne pas inclure try-catch ? C'est parce que try-catch présente plusieurs problèmes.

try-catch-finally

La structure try-catch est une construction destinée à gérer les situations d'erreur et d'exception qui peuvent survenir pendant l'exécution d'un programme (runtime). De plus, la clause finally contient le code qui doit être exécuté impérativement, qu'une exception ait été levée 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 » ou « Droits d'écriture sur disquette refusés ». À cette époque, les développeurs, lorsqu'une erreur survenait, la throwaient jusqu'au point de gestion des erreurs pour la traiter de manière centralisée. Dans ce contexte, la construction try-catch fonctionnait efficacement.

Cependant, avec le temps, la situation a évolué. La logique métier est devenue plus complexe, les bases de données et les transactions sont apparues, il a fallu interpréter d'innombrables messages de requête en appelant de nombreuses API via le réseau, et même avec l'avènement de la programmation concurrente, les erreurs devaient être gérées dans des threads autres que le thread principal.

Les erreurs sont devenues trop complexes pour être gérées en un seul endroit, et aucun endroit ne pouvait assumer la responsabilité de toutes les erreurs. C'est ici qu'un problème grave survient avec le try-catch.

Le Transfert de Responsabilité du try-catch

Le try-catch est, en un mot, une méthode par laquelle l'entité qui déclenche une erreur transfère la responsabilité (le traitement ultérieur) de cette erreur à quelqu'un d'autre. Ce destinataire peut être la clause catch, sa méthode parente, ou le parent du parent du parent du parent... de quelqu'un d'autre. En d'autres termes, dans un monde où le traitement des erreurs devient de plus en plus abondant et complexe, la méthode adoptée par try-catch est de dire : « quelqu'un s'en occupera ». Examinons 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    // Affiche la trace de la pile de l'exception.
8    e.printStackTrace();
9}

Le problème avec le code ci-dessus est qu'il n'est pas clair qui est responsable du traitement de printStackTrace, et il est impossible de savoir quel code a provoqué l'erreur. Le problème s'aggrave encore à mesure que la logique à l'intérieur de l'instruction try augmente. Mais paradoxalement, à mesure que le développement devenait plus complexe, les développeurs sont devenus dépendants des structures try-catch qui transféraient la responsabilité, ont cessé de se soucier de la gestion des erreurs, leur sens des responsabilités s'est estompé, et ils ont finalement oublié 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 dispose de plusieurs systèmes conçus pour guider les développeurs vers de bonnes pratiques, plutôt que de les laisser s'engager sur de mauvaises voies. panic-recover en est un exemple. ​ À première vue, panic et recover peuvent sembler similaires à try-catch, mais ils diffèrent par le fait qu'ils ne rejettent pas la responsabilité à l'extérieur lorsqu'un problème survient. En Go, lorsqu'un panic se produit, la résolution doit avoir lieu à l'emplacement du panic plutôt que de propager la valeur à l'extérieur. Cela confère aux développeurs la responsabilité de la gestion des erreurs, les incitant à réfléchir plus profondément à où, qui et comment l'erreur doit être traitée. Cela garantit l'autonomie de l'utilisateur tout en laissant une marge de réflexion.

De plus, le choix du mot "panic" est également excellent. Contrairement à try-recover, panic-recover impose aux développeurs, par le simple mot, la pression de l'utiliser uniquement dans des situations d'erreur flagrantes, et non dans des situations d'exception. Naturellement, les développeurs n'abusent pas de recover et ne l'utilisent que là où c'est nécessaire. Cela contribue grandement à la rédaction de code concis en Go.