Greg Hauptmann
2007-Mar-01 20:46 UTC
any advise on exception / error handling approaches/priniciples in controllers/views???
Hi,
Can I ask for some advise re what the best practice is for handling
exceptions & errors through my rails code from the point of view of how to
display them back to the user? Some items I''d love to be covered
include:
* is the principle that ALL exceptions (even those the application might not
to be able to do anything about) should be caught and then the application
then decides what text and view .rhtml? Or should the approach be to allow
exceptions to occur and the rails framework to then pass this to a general
error page?
* errors/exceptions that may occur in the action record / data layer - what
categories of errors/exceptions here should be either (a) returned as call
didn''t work or (b) exception. That is, from a best practice point of
view
are there 2 categories of errors/exceptions in the data layer that should be
acknowledged and handed differently in terms of how they are captured and
passed back to the controller layer? (e.g. catch exception and process in
model code and return appropriate response, OR through to an approach like:
any issue that occur in the rails or database itself that get raised as an
exception, don''t try to catch them, but let the exception be thrown
back to
the controller (at which point my first question kicks in re whether the
controller should catch these areas and process or let the rails framework
through to a general application error page)
* where can I see all the possible errors like RoutingError,
UnknownAction...? Is it enough to stick with the standard rails
rescue_action_in_public method (see below)?
def rescue_action_in_public(exception) #:doc:
case exception
when RoutingError, UnknownAction
render_text(IO.read(File.join(RAILS_ROOT,
''public'', ''404.html'')),
"404 Not Found")
else
render_text(IO.read(File.join(RAILS_ROOT,
''public'', ''500.html'')),
"500 Internal Error")
end
end
* allocation of specific error numbers against each specific error the
application catches/can create?
* separate log file for error details in a specific parseable/setout format
(e.g. for a paging system to reference) in additional to standard log file
which contains various other details like rails SQL / timing information, or
full exception stack details
* an action''s render - this won''t be reached if I through an
exception
before this point or there is a rails exception I don''t catch before
this
point no?
* anything else related to monitoring application health?
Thanks
Greg
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
Greg Hauptmann
2007-Mar-02 20:20 UTC
Re: any advise on exception / error handling approaches/priniciples in controllers/views???
[bump - still very keen to hear back if possible:) ] On 3/2/07, Greg Hauptmann <greg.hauptmann.ruby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Hi, > > Can I ask for some advise re what the best practice is for handling > exceptions & errors through my rails code from the point of view of how to > display them back to the user? Some items I''d love to be covered include: > > * is the principle that ALL exceptions (even those the application might > not to be able to do anything about) should be caught and then the > application then decides what text and view .rhtml? Or should the approach > be to allow exceptions to occur and the rails framework to then pass this to > a general error page? > > * errors/exceptions that may occur in the action record / data layer - > what categories of errors/exceptions here should be either (a) returned as > call didn''t work or (b) exception. That is, from a best practice point of > view are there 2 categories of errors/exceptions in the data layer that > should be acknowledged and handed differently in terms of how they are > captured and passed back to the controller layer? ( e.g. catch exception > and process in model code and return appropriate response, OR through to an > approach like: any issue that occur in the rails or database itself that get > raised as an exception, don''t try to catch them, but let the exception be > thrown back to the controller (at which point my first question kicks in re > whether the controller should catch these areas and process or let the rails > framework through to a general application error page) > > * where can I see all the possible errors like RoutingError, > UnknownAction...? Is it enough to stick with the standard rails > rescue_action_in_public method (see below)? > > def rescue_action_in_public(exception) #:doc: > case exception > when RoutingError, UnknownAction > render_text(IO.read(File.join(RAILS_ROOT, ''public'', ''404.html'')), > "404 Not Found") > else > render_text(IO.read(File.join(RAILS_ROOT, ''public'', ''500.html'')), > "500 Internal Error") > end > end > > * allocation of specific error numbers against each specific error the > application catches/can create? > > * separate log file for error details in a specific parseable/setout > format (e.g. for a paging system to reference) in additional to standard > log file which contains various other details like rails SQL / timing > information, or full exception stack details > > * an action''s render - this won''t be reached if I through an exception > before this point or there is a rails exception I don''t catch before this > point no? > > * anything else related to monitoring application health? > > Thanks > Greg > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
dont let the user see the raw error and give them a nice page, explaining that it aint their fault. (most users will blame there self''s) There is also a nice plugin out there that will email every time a error occur''s -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---