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.