tuto – ruby – gestion d’erreurs

Comme je l’ai abordé dans le billet sur ruby – mysql, la gestion d’erreur est un composant essentiel de la programmation dans les cas où les réponses aux requêtes sont incertaines.

Dans le requêtage http avec mechanize par exemple, les résultats peuvent varier, d’un code retour 500, 404, 403,
ou 200 en cas de retour ok(le code retour 200 est équivalent à « SUCCESS »).

 

Vous pouvez vous référer à la page wiki suivante pour les différents codes retour http possible =>

http://fr.wikipedia.org/wiki/Liste_des_codes_HTTP

 

Le code ci-dessous est basée sur une structure begin / rescue avec des rescue multiples afin de pouvoir gérer différents types d’erreur.
On part avec un agent déjà créée (cf un autre billet contenant la création d’un agent, celui avec le randomize sur le user agent).

 

On commence (begin) par effectuer un http get sur google.fr, on affiche la page web récupérée et on retourne vrai :

begin    
    page = @agent.get 'http://www.google.fr/'    
    puts page. body    
    return true

 

En cas de plantage dans le begin, c’est la librairie mechanize qui prend le dessus sur la gestion d’erreur, donc on gère d’abord ce type d’erreur.
On affiche sur la sortie le message d’erreur (exception.message) et on peut même retracer l’anomalie plus en détail (exception.backtrace.inspect).
On renvoi faux ensuite :

      rescue Mechanize::ResponseCodeError => exception
              puts "mechanize error "+ exception.message
              puts exception.backtrace.inspect  
              return false

 

En cas de plantage sur une erreur de type net/http, on affiche sur la sortie standard :

      rescue Net::HTTPBadResponse , Net::HTTP::Persistent::Error, Errno::ECONNRESET=> e
              puts "net exception "+ e.to_s
              return false

 

Si un timeout se produit (la variable read_timeout est paramétré lors de la création de l’agent), on affiche qu’il s’agit d’un timeout :

      rescue Timeout::Error => e
              puts "timeout : "+e.to_s
              return false

 

Enfin, pour tout autre source de plantage dans le begin, on affiche là aussi sur la sortie standard :

      rescue => e
              puts  "another rescue type :> #{e.to_s}"
              return false
      end

 

Lorsqu’on code sur sa propre ip en local, qu’elle n’est pas partagé, il y a peu de chance que vous rencontriez les anomalies décrites dans chacun
des rescue ci-dessus. En revanche, si on se sert de proxy publiques pour les requêtes, il y a fort à parier que le proxy utilisé à un instant T change
d’état à un instant T+1, c’est alors à ce moment que la gestion d’erreur fera ses preuves.