Gestion des erreurs 404 et 500 en Ruby on Rails

Concept

La gestion native des erreurs en ROR souffre de deux manques : d’abord, les erreurs ne sont pas chartées selon le style de votre application, ensuite elles n’alertent pas les développeurs de ce qui s’est produit. Le code ci-dessous peut être placé directement dans l’application ou au sein d’une gem.

Étape 1 : Intercepter les erreurs 404, 422 et 500

Dans le routeur d’URL, ajouter les lignes suivantes :

Lorsqu’une erreur se produit, le moteur de Rails appelle automatiquement ces routes. En ajoutant les routes ci-dessus, on va pouvoir modifier le comportement natif de votre appli en les interceptant dans nos méthodes.

Étape 2 : Méthodes dans le contrôleur

Tout commence par la création d’un contrôleur dédié :

Ce code est simplifiable si vous ne le placez pas au sein d’une gem, mais bon, ça peut rapidement devenir un couteau suisse dans tous vos projets.

Étape 3 : le mailer

Bon là rien d’exceptionnel :

Étape 4 : Les vues des mailers fraichement créés

Pour les 404 je vous suggère d’extraire quelques infos utiles telles que @requete.remote_ip, @requete.user_agent, @requete.request_method, @requete.original_url ou encore @requete.filtered_parameters.to_s (les paramètres de la requête).
Pour les 500, vous pouvez ajouter :

Étape 5 : les vues des méthodes en question

N’oubliez donc pas de créer les vues correspondant aux méthodes selon les choix que vous aurez réalisé à la lecture de l’article.

Nous sommes à l’écoute de toute suggestion car la gestion des erreurs ne semble pas très élaboré d’origine.

2 réflexions au sujet de « Gestion des erreurs 404 et 500 en Ruby on Rails »

  1. Salut ! Une suggestion : pour les notifications d’erreurs ne pas faire ça soi même. Bugsnag, Rollbar, Honeybadger ou n’importe quel autre service. La stack trace est bien plus complète, on peut brancher Slack, Redmine, Trello ou autre, on peut l’utiliser aussi en JS, etc. Pour de l’auto hébergé il y a errbit : https://github.com/errbit/errbit

  2. Pour les erreurs il suffit de modifier les fichiers public/404.html et public/500.html. Pour avoir le style de l’application, il faut copier les assets sans le fingerprint au deploy et les référencer depuis ces pages.

    Un article qui explique les options pour copier les assets sans fingerprint : https://bibwild.wordpress.com/2014/10/02/non-digested-asset-names-in-rails-4-your-options/

    La rake task (à adapter, notamment le nom du manifest pour une version récente de Sprockets) : https://github.com/team-umlaut/umlaut/blob/5edcc609389edf833a79caa6f3ef92982312f0c5/lib/tasks/umlaut_asset_compile.rake

    Une autre option plus simple consiste à rsync les assets vers public, mais cela ne copie pas les assets des gems comme TinyMCE.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.