Les périls de “rescue Exception” (en)

Le rappel est bon, mais un rescue Exception=> e a sa place dans un programme Ruby.

Je déteste qu'un programme crashe sans explication et en laissant tout en plan. Un rescue Exception => e permet de quitter proprement, même dans des circonstances exceptionnelles. Idéalement, il doit n'y en avoir qu'un seul, au plus au niveau du code exécuté.

Il intercepte les interruptions, effectivement, et aussi d'autres erreurs non gérées pour lesquelles le programme se content de logguer l'erreur, de procéder au nettoyage des fichiers temporaires, puis de terminer l'exécution.

Ne bannissez pas le rescue Exception => e !

En général, l'utilisation systématique des blocs fait que j'ai rarement besoin de nettoyer quand une exception est levée, et dans les autres cas, je préfère utiliser ensure.

Par contre, pour logger des exceptions, rescue Exception => e peut effectivement avoir sa raison d'être.

Exact, le nettoyage a plus sa place dans le ensure. Et le rescue Exception => e, quant à lui, devrait se limiter à logguer l'erreur quelque part avant de quitter proprement ou de re-lever l'exception pour l'appelant s'il y a lieu.

``rescue => e``, en général (ou juste ``rescue`` sans précision), n’est pas beaucoup mieux : une exception doit marquer une erreur qui ne fait pas partie de l’exécution normale du programmer. Un ``rescue => e``, ça veut plus ou moins dire « je me fiche que ça tourne mal ! ». Il vaut mieux utiliser des exceptions précises pour réagir correctement dans les cas ou quelque chose peut aller mal (par exemple, quand on fait de l’IO, il faut s’attendre à des SystemCallError).

Ce ``rescue => e`` tend à passer sous silence des bugs. La syntaxe inline est pire, et beaucoup de gens écrivent à tort des choses comme (extrait de scanf.rb, faisant partie de la bibliothèque standard de Ruby pourtant) : seek(start_position + matched_so_far, IO::SEEK_SET) rescue Errno::ESPIPE