Tag: routing error

Rails3 + własne dynamiczne strony błędów (404 i 500)

Uwaga! - kod ten działa TYLKO dla Railsów3.
Opis "starego" routingu błędów dostępny tutaj.

Migrując Susanoo na Rails 3.0.0 okazało się że poprzez zmiany w middleware i obsługę błędów w inny sposób - mój system zarządzania renderowaniem błędów nie działa.Szczerze mówiąc niezbyt mnie to martwiło, ponieważ nie był on "aż tak" fajny. Korzystając z okazji (czyt. nie mając wyjścia) zacząłem googlać za sposobami rozwiązania tego problemu. Metody takie jak

rescue_action_in_public
rescue_action_locally

przestały działać.Pierwszą myślą jaka mi się nasunęła, było obsługiwanie błędów przerzucając "złe trafienia" po routsach do kontrolera błędów

match ':action', :to => "errors#index"
match '*anything', :to => "errors#index"

niestety rozwiązanie takie miało jedną wielką wadę - nie obsługiwało internal server error'ów. Błędy 404 mogłem za jego pomocą obsługiwać, jednak w wypadku wystąpienia 500 - nic z tego. Dodatkowo takie rozwiązanie nie działało w wypadku zgłoszenia wyjątkuActiveRecord::RecordNotFound.Nie było więc wyjścia ;) trzeba było napisać własny plugin. Poniżej opiszę jak działa, a tymczasem dla niecierpliwych link do githuba:
http://github.com/mensfeld/custom_errors_handler.

W README jest dokładnie opisane jak go wykorzystać, jednak tutaj wspomnę dla pewności:

  • wrzucamy dop vendor/plugin
  • tworzymy 404.erb, 500.erb w views danego kontrolera/modułu lub w views kontrolera/modułu ale w subkatalogu "layouts"
  • reset serwera
  • "sztuczne" bądź też prawdziwe wygenerowanie 404/500
  • ?
  • profit ;)

A teraz omówienie pluginu.

Cała zabawa w utworzenie tego typu pluginu, polegała na “przejęciu” błędów z ActionDispatch::ShowExceptions. Można to było zrobić, nadpisując metodę render_exception.

Jak widać poniżej, sam kod nie jest wielki. Przechwytuje on błędy i przekazuje je do kontrolera CustomErrorsHandler gdzie nastąpi rozpoznanie błędu i wyrenderowanie odpowiedniego szablonu.

module ActionDispatch
  class ShowExceptions
    private
      def render_exception_with_template(env, exception)
        body = CustomErrorsHandlerController.action(rescue_responses[exception.class.name]).call(env)
        log_error(exception)
        body
      rescue
        render_exception_without_template(env, exception)
      end

      alias_method_chain :render_exception, :template
  end
end

Skoro mamy już przekazywanie błędów, przejdźmy do kontrolera który się tym zajmuje. Jest to CustomErrorsHandlerController.

Obsługuje on 3 rodzaje błędów:

  1. :internal_server_error (500)
  2. :not_found (404)
  3. :unprocessable_entity (403)

Korzysta także z 3 metod pomocniczych:

  1. error_layout
  2. template?
  3. translate_error

Zanim opiszę kod odpowiedzialny za działanie, opiszę każdą z tych metod.

Pierwszą będzie translate_error:

  def translate_error(e)
    case e
    when :internal_server_error then '500'
    when :not_found then '404'
    when :unprocessable_entity then '500'
    else '500'
    end
  end

Metoda ta zwraca "liczbowy" odpowiednik danego błędu. Potrzebujemy tego, ponieważ w naszych szablonach nie chcemy używać szablonuinternal_server_error.erb ale raczej 500.erb.

Druga czyli template? zwraca nam informację czy dany plik szablonu istnieje. Ścieżkę podajemy zaczynając od widoków, czyli nie app/views/jakis_kontroler/, ale /jakis_kontroler/. Kod tej metody jest dość prosty:

  def template?(template)
    FileTest.exist?(File.join(Rails.root, 'app', 'views', "#{template}.erb"))
  end

Ostatnią metodą jest error_layout. Odpowiada ona za znalezienie szablonu błędu, przeszukując strukturę katalogów, zaczynając od ścieżki "najgłębszej", stopniowo idąc wyżej w hierarchii katalogów.

  def error_layout(path, e)
    e = <strong>translate_error</strong>(e)
    path= path.split('/')
    path.size.downto(0) do |i|
      VALID_ERRORS_SUBDIRS.each { |lay_path|
        template_path = File.join((path[0,i]).join('/'), lay_path, e)
        return template_path if template?(template_path)
      }
      template_path = File.join(path[0,i], e)
      return template_path if template?(template_path)
    end
    e
  end

Metoda ta przyjmuje dwa argumenty - pierwszym z nich jest path. Path jest ścieżką skąd wywołany był błąd. Czyli przykładowo: jeśli błąd wystąpił w kontrolerze MyTest w module Samples (Samples::MyTest), w akcji index, to będzie następujący:

/samples/my_test/index

Parametr e jest to nazwa błędu, którą następnie tłumaczymy naszą metodą translate_error.

Mając ścieżkę rozbijamy ją tak, aby mieć jej kolejne "stopnie".

    path= path.split('/')

Następnie "przelatujemy" całą strukturę sprawdzając takie katalogi (w kolejności):

/samples/my_test/index/layouts
/samples/my_test/index
/samples/my_test/layouts
/samples/my_test/
/samples/layouts/
/samples/
layouts

Skąd się wzięło "layouts"? Otóż w stałej VALID_ERRORS_SUBDIRS mamy zdefiniowane podkatalogi katalogów które sprawdzamy, tak by sprawdzić także je. Dzięki temu, layouty błędów możemy umieszczać w podkatalogach layouts danych kontrolerów/modułów, nie zaś w katalogach głównych.

Zdefiniowane jest to jako stała, ponieważ może ktoś z Was zapragnie mieć inne podkatalogi na błędy (np podkatalog errors). Wtedy wystarczy sobie takowe dopisać.

Następnie łączymy ścieżkę oraz kod błędu i sprawdzamy metodą template? czy taki szablon istnieje. Odpowiada za to, ten fragment kodu:

      VALID_ERRORS_SUBDIRS.each { |lay_path|
        template_path = File.join((path[0,i]).join('/'), lay_path, e)
        return template_path if template?(template_path)
      }
      template_path = File.join(path[0,i], e)
      return template_path if template?(template_path)

Na samym końcu, jeśli żaden z naszych "dynamicznych" 404/500 nie został znaleziony, zwracamy standardowy 404/500. Skutkuje to wyrenderowaniem layoutu znajdującego się w /public.

To by było na tyle. Jeśli chodzi o testy do tego pluginu, to nie bardzo wiem jak przetestować ActionDispatch::ShowExceptions. Jeśli ktoś z Was to potrafi, prosiłbym o kontakt.

Handling custom 404 and 500 errors in Rails 2.3

We all need to handle 404 and 500 errors. Rails handle them differently in different environments.

In development, when we request a non existing resource, we will see:

Routing Error

No route matches “/dummy_controller/non_existing_action” with {:method=>get}

Similar situation occurs, when requesting non existing action but in an existing controller:

Unknown action

No action responded to smthn_weird. 
Actions: index, load_adverts, login and logout

Even in production when we make a request from 127.0.0.1 (aka localhost), the request is handled as local.

When we develope our software, informations like those mentioned above are useful, however sometimes we would like to do something else. There might be a situation when you would like to:

  1. redirect all 'missed' requests into a specified controller (withouth showing 404)
  2. test 404 and 500 behavior
  3. show extended info even in production mode
  4. render different error templates, depending on a module (admin, shopping, etc)
  5. do any other weird kind of stuff

So, let's overwrite Rails default behavior.

Put into config/environment.rb:

# Show 404 errors
SHOW_404 = true
# Show error template (or render extended Rails info)
SHOW_EXTENDED_404 = false
# Don't show 500 - instead render 404 
SHOW_ONLY_404 = false 

We can use those constants to manipulate Rails "error flow":

  • SHOW_404 = false - don't show 404 - use default controller and action to handle response
  • SHOW_404 = true – render 404 error
  • SHOW_EXTENDED_404 = true – show extended 404 info
  • SHOW_EXTENDED_404 = false – render default 404 template (in any of environments)
  • SHOW_ONLY_404 – don't show 500 errors - handle them like 404

Next, add into config/routes.rb (just before final "end"):

# 404 route
map.connect "*anything", :controller => "default_controller", :action => "index" if !SHOW_404

This will redirect into default controller any requests which do not fit anywhere else. It is worth mentioning here, that it is often not the desired behavior and the user can feel lost when suddenly he will see main page instead of 404 error.

When we use namespaces(modules) and we would like to handle errors differently, depending on a module, we should add:

admin.connect "*anything", :controller => "default_controller", :action => "index" if !SHOW_404
admin.connect ':action' , :controller => "module", :action => "index" if SHOW_404

and for each module also:

admin.controller_name 'controller_name', :controller => 'controller_name'

Now overwrite default error handling methods in controllers/application_controller.rb :

def rescue_action_locally(exception)
	if SHOW_EXTENDED_404
		super exception
	else
		rescue_action_in_public(exception)
	end
end

Second method:

def rescue_action_in_public(exception)
	if SHOW_EXTENDED_404
		rescue_action_locally exception
	else
		case exception
		when ActiveRecord::RecordNotFound, ActionController::UnknownAction, ActionController::RoutingError
			render_error 404
		else
			if SHOW_ONLY_404
				render_error 404
			else
				render_error 500
			end
		end
	end
end

So, we have error handling, but we still lack two things:

  1. render_error method
  2. path to the errors templates.

Copy 404.html and 500.html from public into views/shared/ and change file extension to .erb. Create in views/layouts/ custom error templates and do not forget to yield :). After that - tell Rails about those templates:

  
PATH_404 = 'shared/404'
PATH_500 = 'shared/500'
ERROR_LAYOUT = 'layouts/server_errors'

Finally render_error method:

def render_error(error_nr = 404)
	p404 = PATH_404; p500 = PATH_500
	lay404 = ERROR_LAYOUT; lay500 = ERROR_LAYOUT
	if block_given?
 		feedback = yield
 		p404 = feedback[0]
 		lay404 = feedback[1]
 	 	p500 = feedback[2]
  	 	lay500 = feedback[3]
	end

	case error_nr
	when 404 || SHOW_ONLY_404
 		render :template => p404, :layout => lay404, :status => "404"

	else
		render :template => p500, :layout => lay500, :status => "500"
	end
end

Why I use yield? I have not found a way to pass template parameters from our class into base class. Ofcourse it is possible to overwrite whole render_error in all subclasses but it is not DRY. Instead of this, you can do it like this:

def render_error(error_nr = 404)
	super do [ 'admin/shared/404', false, 'admin/shared/500', false] end
end

First argument contains error partial path, second - layout path. When there is no layout path (error template has already embed layout) - just put false.

Copyright © 2024 Closer to Code

Theme by Anders NorenUp ↑