[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