[Rails] Proposal for 'nicer' error rescue solution

Johan Sörensen johans at gmail.com
Sun Dec 12 23:10:34 GMT 2004


Not sure if this is exactly what you mean, but there is the
resue_action_in_public method[1]

You'll need to add the following to one of your enviroment files (like
production.rb):
ActionController::Base.consider_all_requests_local = false

In my case, I have a custom template that displays the error:
  def rescue_action_in_public(exception)
    @exception = exception
    render 'rescues/error'
  end

Granted, the method above is rather "dumb" since its not really
showing any friendlier error msgs than what rails spits out, but at
least it integrates better in a site than the standard rails error
pages. I guess you could flesh out the above with more logging,
translation of rails errors to "user friendly errors", or sending of
emails to admin etc.

[1] http://api.rubyonrails.org/classes/ActionController/Rescue.html#M000006

-- johan


On Sun, 12 Dec 2004 17:55:26 -0500, Nicholas Seckar <nseckar at gmail.com> wrote:
> It would be nice if custom handling of public errors didn't require
> diving into rescue.rb.
> 
> Ideally:
>   - We could write custom templates for arbitrary errors
>   - We could use two different templates for public and private handling
>   - We could specify the response code based upon exception class
>   - We could use the same template for more than one error
>   - Missing templates would fall back to a generic template (as they do now.)
> 
> To implement these changes:
>   - .../templates/rescues be changed to hold subdirs private/ public/
> and possibly common/
>   - Configuration support be added for specifying response codes and
> exception templates.
> 
> It would be best if only special cases had to be configured. Default
> template names could be guessed using the inflector; the default
> response code could be configurable or simply "500 Internal Error" as
> it is now.
> 
> Another option might be app specific error templates, but this is
> (even) less of a priority.
> 
> These changes are obviously not a priority, and they might not even be
> liked by all. So, what are your thoughts: should this be implemented?
> Is it necessary or does it fall outside the rule of 'less software?'
> _______________________________________________
> Rails mailing list
> Rails at lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> 


-- 
Johan Sørensen
Professional Futurist
www.johansorensen.com


More information about the Rails mailing list