Exemple : `rescue` une erreur de connexion réseau

Le talon d'Achille de toute application connectée

Dans le développement moderne, très peu d'applications vivent en autarcie. La plupart interagissent avec le monde extérieur, notamment en appelant des APIs externes pour récupérer ou envoyer des données. Nous avons vu comment faire cela facilement avec la gem HTTParty. Mais que se passe-t-il si votre connexion internet est coupée au moment où vous lancez ce script ? Ou si le serveur de l'API est temporairement indisponible ?

Sans mécanisme de protection, la réponse est simple : votre application va crasher. Une erreur de connexion va lever une exception non gérée, et tout s'arrêtera. Pour un utilisateur, c'est une très mauvaise expérience. Pour un développeur, c'est le signe d'une application fragile. C'est précisément pour ce genre de scénario, imprévisible et hors de votre contrôle, que la gestion des exceptions a été inventée.

Le code fragile : un appel API sans filet de sécurité

Imaginons un script simple qui a pour but de récupérer des informations sur un utilisateur aléatoire depuis l'API publique `randomuser.me`. Le code est direct et fonctionne parfaitement... dans des conditions idéales.

require 'httparty'

def fetch_random_user
  puts "Tentative de connexion à l'API..."
  response = HTTParty.get('https://randomuser.me/api/')
  user_data = response.parsed_response
  puts "Utilisateur récupéré avec succès !"
  user_data
end

fetch_random_user

Si vous exécutez ce code avec une connexion internet active, tout ira bien. Maintenant, essayez de le lancer après avoir désactivé le Wi-Fi de votre ordinateur. Vous obtiendrez un crash immédiat avec une erreur comme SocketError: Failed to open TCP connection. Le programme s'arrête violemment car il ne sait pas comment réagir à cette situation.

Comment mettre en place le filet de sécurité avec `begin/rescue` ?

Nous allons maintenant rendre ce code robuste en l'enveloppant dans un bloc begin/rescue. L'idée est de "tenter" l'opération réseau et, en cas d'échec, d'"intercepter" l'erreur de connexion spécifique pour exécuter un code alternatif, comme afficher un message d'erreur clair.

Pour les problèmes de réseau, plusieurs types d'exceptions peuvent être levées. Les plus courantes sont SocketError (souvent un problème de DNS ou d'accès au réseau) et Net::OpenTimeout (le serveur distant ne répond pas à temps). Nous pouvons intercepter les deux.

require 'httparty'

def fetch_random_user_safe
  begin
    puts "Tentative de connexion à l'API..."
    response = HTTParty.get('https://randomuser.me/api/')
    user_data = response.parsed_response
    puts "Utilisateur récupéré avec succès !"
    return user_data
  rescue SocketError, Net::OpenTimeout => e
    puts "-" * 40
    puts "ERREUR : Impossible de se connecter au service."
    puts "Veuillez vérifier votre connexion internet ou réessayer plus tard."
    puts "Détail technique : #{e.message}"
    puts "-" * 40
    return nil # C'est une bonne pratique de retourner nil en cas d'erreur
  end
end

fetch_random_user_safe

Désormais, si vous exécutez ce code sans connexion internet, le programme ne crashera plus. Il exécutera le code du bloc rescue, affichera un message compréhensible et se terminera proprement en retournant nil.

Anatomie d'une bonne gestion d'erreur réseau

Analysons les éléments clés qui rendent notre nouvelle version professionnelle :

• Spécificité : Nous ne faisons pas un rescue à nu. Nous ciblons explicitement SocketError et Net::OpenTimeout. Cela signifie que si une autre erreur inattendue se produit (par exemple, une faute de frappe dans notre code), le programme plantera, ce qui est souhaitable pour nous alerter du bug.
• Capture de l'exception : En utilisant => e, nous capturons l'objet exception dans la variable e. Cela nous permet d'afficher e.message, qui peut donner des indices techniques précieux pour le débogage.
• Retour de valeur explicite : La méthode ne se contente pas d'afficher un message. Elle retourne une valeur claire pour indiquer le succès (les données de l'utilisateur) ou l'échec (nil). Le code qui appelle cette méthode peut alors facilement vérifier le résultat : user = fetch_random_user_safe; if user ....

Cette approche transforme une source potentielle de crash en un comportement prévisible et gérable. Dans le projet final qui vous attend, où vous interagirez avec une API, l'application de ce principe ne sera pas une option, mais une nécessité pour construire une application de qualité.