#53 Handling Exceptions (revised)

In order to test the dynamic generation of error pages, you need to be in production environment, which is incompatible with running your entire test suite, normally in test environment.

Similarly hacking the config.consider_all_requests_local parameter may is not viable except as a short-term hack to see dynamic error pages operating in dev or test environment.

So I found it best to move the ErrorsController and associated views into a Rails engine... that way it can have a test suite of its own, running the tests in production environment.

@laylester, could you please put out a sample/example on Github?
Thanks.
Bharat

@Bharat Ruparal
https://github.com/lazylester/error_pages_engine

This is certainly an area of my apps that needs some TLC. Thanks!

Nice episode, but it would be beneficial to add something like response.status = request.path[1..-1] to make the status code carry over (if anyone knows of a nicer way to do this, speak up).

Otherwise, the error pages will all have a status of 200 OK since the error controller itself responded normally.

Has anyone found a good way to test this with RSpec?

Thanks Ryan, exactly the right episode at the right time :)

One note on using curl. It seem easy and nice to simply generate the static pages via "curl http://localhost:3000/errors/404 > public/404.html".

But beware that you generate them under the development environment but serves them in production. At least when they are checked in and deployed to production.

Your pages may contain stuff that should only be visible in development mode and not on staging or production.

So you may need to run the curl command on production to get the correct pages. That can be done manually after each deployment but that's cumbersome.

One can add a capistrano recipes that runs after deploy:restart (when the app is up using the maybe new layout). But then you great the pages whenever you restart the app.

And with static pages you cannot serve different pages for different context. For example a signed in user will get a 404 page without his user menu (preferences, account, ...) and
maybe without the logout button. That can be ok in your case but should be considered.

If you are fine with static pages you may generate them outside the controller via a rake tasks and run that task on every deployment via after "deploy:create_symlink", "deploy:error_pages:create"

We tried this but now using your solution via the ErrorsController.

Thanks!

Nice episode.
I just had to handle a situation where I had to disply a custom error message on a ActiveRecord::RecordNotFound Exception for a specific controller.
Although this episode I can't figure out how to set a custom error message.

This doesn't work with airbrake :s
Do anyone know a solution to this?

Thank you for awesome screencast. I got inspired and wrote little more enhanced version of this (for example fallback to generic error message layout, and hiding 500 error messages in production): https://github.com/sheerun/rails4-bootstrap/commit/5c2df5a108ad204bc407183b959bb355ff5ed53d

if anyone needs a rake task for generating public pages you can use mine https://github.com/equivalent/forgotten_software/blob/master/2013-10-custom_error_pages/lib/tasks/generate_error_pages.rake

Great screencast as always! Some reason, when trying to go directly to the url, http://localhost:3000/errors/404

Rails wants to look in errors/errors folder in the views.

ActionView::MissingTemplate at /errors/404
Missing template errors/errors/404, application/errors/404 with {:locale=>[:en], :formats=>[:html], :handlers=>[:erb, :builder, :coffee, :haml]}.

It appears that config.exceptions_app = self.routes no longer works in Rails 4. I implemented custom error pages using this when my application was 3.2.13. However when I rewrote the application in Rails 4.0.0 it completely ignored my custom error pages. Thankfully I could move them to the public folder (no ruby code) even with localization. All I did was to create separate views for each locale (i.e. 404.en.html, 404.fr.html) in the pubic folder. No other changes were needed. When I get a 404 error for locale en the English error page displays. When I get a 404 error for locale fr the French error page displays. Maybe there is a way to use html.erb files in the public folder to access some of the information in this wonderful RailsCast episode.

Tried in Rails 4, works fine. Except calling directly to errors/404 (for using the curl stuff). However Mike Henke pointed to the correct solution, at least in Rails 4 I had to remove the action: part. After that it worked fine. Including the status passing it would be:

def show
  status_code = ActionDispatch::ExceptionWrapper.new(env, @exception).status_code
  render request.path[1..-1], status: status_code
end

Also, just using the dynamic pages would result in my feature specs into a ActionView::MissingTemplate error. Even with config.consider_all_requests_local = false in the test.rb within the environments folder.

The only thing that helped me so far was to create static error pages using the (now working) curl command.

I noticed that in 404 cases the ExceptionWrapper somehow returned 500 (not sure why). When really an exception occured, it would however render a 404 instead of a 500.

In stead of my previous comment, I have used:

status = params[:status] || ActionDispatch::ExceptionWrapper.new(env, @exception).status_code

Also, I figured that simply creating static error pages (even from PROD environment) is not sufficient in Rails 4. The whole reason I am using dynamic pages is because the assets no longer are offered in a non-digest way. Therefor I cannot generate static pages and commit them, as the digest will change per deploy on prod (precompiling assets everytime). A github issue (https://github.com/rails/sprockets-rails/issues/49) has been made a while back about this.

It would be nice if Ryan could elaborate/update this screencast about this issue.

Really USEFULL Thanks Ryan

I'm sure this is simple, but I can't find a way to manually send someone to a 404 (using the middleware approach). For example, I want to "hide" private widgets if the widget author is not the current user:

class ThingsController < ApplicationController
  def show
    @thing = Thing.find(:id)
    if @thing.user != current_user && @thing.is_private?
      # What do I put here to fake a 404?
    end
  end
end

I tried render text: "Not found", status: 404 but that does exactly that, just renders the text instead of handling it through the errors controller. I also tried render status: 404, but that still shows the record (albeit with a 404 status in the web inspector).

                respond_to do |format|
                        format.html { render action: request.path[1..-1], status: 404 }
                        format.json { render json: {status: request.path[1..-1], error: @exception.message}, status: 404}
                end

Using status respond to the error is better for others system knows what is happeing

This approach is used on our app and currently we are having troubles whenever a gem we are using raises an error - instead of an error message we are getting nginx Bad Gateway pages and nothing in the log and the ErrorsController show action does not get run at all (Could be for another reason and not due to this approach at all - not sure - just seems likely)

good job

Now I finally understand, thanks!

I have investigated your stunning post. This is a unimaginable occupation. I have respected the experience of secluding your post first time

I like your all post. You have done really good work. I appreciate your working style at the end just my request is please share with us some more great post... .

I like your all post. You have done really good work. I appreciate your working style at the end just my request is please share with us some more great post... .

Thanks for the tips and guide. It is very useful tips.

I really wanted to send a small word to say thanks to you for the fantastic points you are writing on this site.

Great post & Best website

I didn't realize I was still considered a new user...

Thanks so much for this wonderful and great website as well as this post.

Good

gc-spiele.de

cool blog

Gracias

Superb post.

Its really awesome

thxks

lovely

ok thanks

Thank you for your work on the blog! You're doing a good job!

penyebab sipilis itu apa

cara menyembuhkan sipilis bagaimaana ya