Menu
Coddy logo textTech

Utiliser `recover`

Fait partie de la section Logique & Flux du Journey GO de Coddy. Leçon 43 sur 68.

Alors que panic arrête votre programme immédiatement, Go offre un moyen de reprendre le contrôle via la fonction recover. La fonction recover vous permet de capturer une panique et de la gérer proprement, empêchant ainsi l'intégralité de votre programme de planter.

Cependant, recover a une exigence très spécifique : il ne peut être utilisé qu'à l'intérieur d'une fonction différée. Lorsqu'une panique survient, Go exécute toutes les fonctions différées avant que le programme ne se termine, donnant à recover une chance d'intercepter la panique :

func riskyFunction() {
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("Recovered from panic:", r)
        }
    }()
    
    panic("something went wrong!")
}

La fonction recover retourne la valeur qui a été passée à panic, ou nil si aucune panique ne s'est produite. Cela vous permet de vérifier si une panique s'est produite et de prendre les mesures appropriées, comme journaliser l'erreur ou effectuer des opérations de nettoyage.

Comme panic, recover doit être utilisé avec parcimonie en Go. On le rencontre le plus souvent dans des scénarios tels que les serveurs web, où vous voulez empêcher qu’une panique liée à une seule requête ne fasse planter l’ensemble du serveur, afin qu’il puisse continuer à traiter les autres requêtes.

challenge icon

Défi

Facile

Créez un gestionnaire de requêtes pour un serveur web qui utilise recover afin de gérer élégamment les paniques et d’empêcher le serveur entier de planter. Ce défi montre comment utiliser recover dans une fonction différée pour intercepter les paniques et maintenir la stabilité du serveur.

Vous recevrez deux entrées :

  • Une chaîne contenant les détails de la requête au format "endpoint,method,action" (par exemple, "/api/users,GET,process")
  • Une chaîne contenant la configuration du serveur au format "server_name,max_requests" (par exemple, "WebServer,100")

Votre tâche consiste à :

  1. Analyser la première entrée en la séparant sur les virgules afin d’obtenir endpoint, method et action
  2. Analyser la deuxième entrée en la séparant sur les virgules afin d’obtenir le nom du serveur et le nombre maximal de requêtes
  3. Convertir la chaîne du nombre maximal de requêtes en entier
  4. Créer une fonction appelée handleRequest qui prend endpoint, method, action et le nom du serveur comme paramètres
  5. Dans handleRequest, ajouter une fonction différée qui utilise recover pour intercepter les paniques :
    • Si une panique est récupérée (recover renvoie une valeur non nulle), afficher : "Server [server_name] recovered from panic: [panic_value]"
    • Après avoir géré la panique, afficher : "Request handling completed safely"
  6. Après la fonction différée, simuler le traitement de la requête selon l’action :
    • Si l’action est "process" : afficher "Processing [method] request to [endpoint]"
    • Si l’action est "panic_nil" : afficher "Attempting dangerous operation", puis appeler panic("nil pointer access")
    • Si l’action est "panic_overflow" : afficher "Attempting resource allocation", puis appeler panic("memory overflow")
    • Si l’action est "panic_timeout" : afficher "Attempting database connection", puis appeler panic("connection timeout")
    • Pour toute autre action : afficher "Unknown action: [action]", puis appeler panic("invalid action")
  7. Dans la fonction principale, afficher le message de démarrage du serveur : "Starting [server_name] with max [max_requests] requests"
  8. Appeler la fonction handleRequest avec les paramètres analysés
  9. Après l’appel de la fonction, afficher l’état du serveur : "Server [server_name] is still running"
  10. Enfin, afficher un résumé :
    • "Server Summary:"
    • "Name: [server_name]"
    • "Max Requests: [max_requests]"
    • "Last Request: [method] [endpoint]"
    • "Action Performed: [action]"
    • "Status: Operational"

Utilisez le package strings pour séparer les chaînes d’entrée sur les virgules et le package strconv pour convertir la chaîne du nombre maximal de requêtes en entier. Ce défi montre comment recover permet aux serveurs de gérer élégamment les paniques inattendues, en empêchant les échecs d’une requête individuelle de faire tomber l’ensemble du système.

Essayez vous-même

package main

import (
	"fmt"
	"strconv"
	"strings"
)

func main() {
	// Lire l'entrée
	var requestDetails string
	var serverConfig string
	fmt.Scanln(&requestDetails)
	fmt.Scanln(&serverConfig)
	
	// Analyser les détails de la requête
	requestParts := strings.Split(requestDetails, ",")
	endpoint := requestParts[0]
	method := requestParts[1]
	action := requestParts[2]
	
	// Analyser la configuration du serveur
	configParts := strings.Split(serverConfig, ",")
	serverName := configParts[0]
	maxRequests, _ := strconv.Atoi(configParts[1])
	
	// TODO: Écrivez votre code ci-dessous
	// Créer la fonction handleRequest avec un mécanisme de récupération (recover)
	// Afficher le message de démarrage du serveur
	// Appeler la fonction handleRequest
	// Afficher l'état du serveur et le résumé
	
}
quiz iconTestez-vous

Cette leçon comprend un petit quiz. Commencez la leçon pour y répondre et suivre votre progression.

Toutes les leçons de Logique & Flux

Entraînez-vous par vous-même : Compilateur Go en ligne