ExceptionHandler Ruby on Rails Gem

ExceptionHandler Ruby on Rails Gem

ExceptionHandler is een “foutpagina’s”-juweeltje voor Ruby on Rails.

Momenteel, met versie 0.7.7.0, is het juweeltje meer dan 170.000 keer gedownload en wordt het algemeen beschouwd als het “beste” juweeltje voor dynamische foutpagina’s voor het framework. Het werkt buitengewoon goed.

Het belangrijkste om te beseffen over ExceptionHandler is dat het in feite is ontworpen om een ​​”vertaal”-systeem te bieden voor Rails-fouten, en deze om te zetten in de juiste HTTP-fout die een webbrowser kan lezen.

U ziet dat, hoewel Rails vanuit zijn kern uitzonderingen kan maken, deze fouten niet zijn wat u in uw browser ziet. U ziet de http-fout die het framework aan de webserver levert. Deze http-fout gaat gepaard met een “HTTP-berichttekst”, die de browser op de pagina weergeeft.

Met andere woorden, als je met Rails-fouten te maken hebt – als je echt “branded”-foutpagina’s wilt tonen (met je eigen lay-out of een andere) – moet je Rails “hacken” om die specifieke pagina’s weer te geven wanneer er fouten optreden. De getoonde pagina’s hebben GEEN invloed op wat de gebruiker ziet in zijn webbrowser; ze zijn er gewoon om hen een “merk”-manier te bieden om ermee om te gaan.

Telkens wanneer Rails een uitzondering opwerpt in zijn toepassing – die fout (het kan van alles zijn, zoals een databaseprobleem of zoiets) is alleen geldig voor de Rails-toepassing. Wat Rails doet, is die fout “vertalen” in een van de twee soorten HTTP-fouten (die een browser kan lezen): 4xx (clientfout) of 5xx (serverfout).

Elke keer dat u een “web”-toepassing gebruikt, verzendt uw computer een verzoek om gegevens op poort 80 van een openbaar toegankelijk IP-adres. Als de andere computer (server) een “webserver”-toepassing op poort 80 heeft, zal deze het verzoek accepteren en reageren met op HTTP gebaseerde gegevens (die doorgaans HTML-code bevatten).

Het hele “web” is een openbare map voor het “internet”, wat betekent dat als u het IP-adres (of een gelijkwaardige domeinnaam) voor een aangesloten computer heeft, u er toegang toe moet hebben via de “HTTP” (Hyper Text Transfer Protocol) . Dit HTTP-protocol is de kern van hoe het “web” werkt en waarom de meeste mensen in de war raken als ze te maken hebben met “fouten” in hun op Rails gebaseerde applicaties.

HTTP-“fouten” zijn eigenlijk helemaal geen fouten, maar foutieve reacties. Elke “fout” die u ziet, is nog steeds een HTML-pagina, weergegeven met een bijbehorende HTTP-statuscode.

Omdat HTTP een “staatloos” protocol is, moet het werken met een zogenaamd “verzoek/antwoord”-patroon – wat in wezen betekent dat elke keer dat u een nieuw verzoek naar een webservice verzendt, dat verzoek als geheel nieuw wordt behandeld.

Dit is in tegenstelling tot “stateful” processen, die “status behouden” tussen verzoeken; in de zin van native applicaties of iets dergelijks. Het punt is dat wat je ziet met HTTP-fouten een reactie is op een foutief verzoek. Het zijn eigenlijk gewoon statuscodes die dat verklaren.

Om dit goed te doen, moet u in staat zijn om op Rails gebaseerde fouten te “vertalen” naar de juiste HTTP-foutreactie. Dit wordt gedaan door de ActionDispatch::ShowExceptions-middleware – die een middleware “hook” (“exceptions_app”) aanroept om te bepalen welk “HTML”-antwoord moet worden weergegeven in de hoofdtekst van het foutieve bericht.

Het gebruikt de hash “rescue_responses” om te bepalen met welke HTTP-foutcode eventuele Rails-uitzonderingen moeten worden afgestemd. Deze hash kan binnen Rails worden uitgebreid, zodat gebruikers verschillende op Rails gebaseerde “uitzonderingen” kunnen toewijzen aan de juiste HTTP-responscode.

Stel dat uw toepassing een fout genereert met ActiveRecord.

Als het een bepaald item in de database niet kan vinden, zal Rails de uitzonderingsklasse ActiveRecord::NotFound verhogen. Dit is geen HTTP-compatibele fout; het is gewoon een uitzondering op “Rails”. De sleutel is dat het moet worden “vertaald” naar een fout die op HTTP gebaseerde browsers kunnen begrijpen. Dit is waar ActionDispatch::ShowExceptions binnenkomt.

ShowExceptions neemt in wezen het exception-object – passeert het door de “rescue_responses”-hash (om een ​​geschikte HTTP-statuscode te krijgen) en – cruciaal – roept de “exceptions_app” middleware hook aan om de “HTTP message body” voor het antwoord te genereren…

wrapper = ExceptionWrapper.new(backtrace_cleaner, exception)

status = wrapper.status_code

request.set_header “action_dispatch.exception”, wrapper.exception

request.set_header “action_dispatch.original_path”, request.path_info

request.path_info = “/#status”

response = @exceptions_app.call(request.env)

Het belangrijkste om hier te beseffen is dat @ Exceptions_app is wat ExceptionHandler is gebouwd om te beheren.

Elke keer dat Rails een uitzondering maakt, blijft het HTTP-protocol hoe dan ook bestaan. Met andere woorden, u moet altijd een HTTP-statuscode en berichttekst naar de verzoekende webbrowser sturen… het verschil zit hem in wat u verzendt.

Het probleem voor Rails is dat @exceptions_app standaard de “routes” gebruikt – wat betekent dat het 404.HTML of 500.HTML laadt uit de /public directory van je applicatie. Hoewel dit werkt, zijn de pagina’s onprofessioneel en statisch.

Om de pagina’s te wijzigen, overschrijft ExceptionHandler de “@exceptions_app” hook met zijn eigen controller en views. Dit betekent dat je in principe “dynamische” webpagina’s kunt oproepen met Rails.

De manier waarop ExceptionHandler werkt, is om de “standaard” lay-out van de toepassing (meestal “toepassing”) te gebruiken voor 4xx-fouten, en een volledig aangepaste “uitzondering”-lay-out op te nemen voor 5xx-fouten. De aangepaste lay-out wordt over het algemeen aanbevolen omdat 5xx-fouten duiden op serverproblemen, wat betekent dat als u een lay-out gebruikt die verwijst naar de database (zoals de meeste “toepassings”-lay-outs doen), dit een oneindige lus kan veroorzaken.

Dit betekent dat als je een fout hebt – stel dat ActiveRecord een record niet uit de database kan laden – Rails nog steeds ActiveDispatch::ShowExceptions zal aanroepen.

Omdat ExceptionHandler echter de hook “exceptions_app” overschrijft, in plaats van dat de statische 404.HTML / 500.HTML-pagina’s worden aangeroepen, worden in plaats daarvan de controller en views-pipeline aangeroepen die door de gem worden geleverd.

Bron: Richard Peck

Affiliate Samenwerkingen
Berichten per categorie