[LRUG] Exceptions as a flow control mechanism
Tim Harding
tim.harding at gmail.com
Wed Dec 19 04:32:17 PST 2007
My second, more succinct, thought about this feature:
Exceptions should be handled at the point you can make a reasonable decision
about what to do with them. This is just another tool to let you do that.
On Dec 19, 2007 6:22 AM, Tim Harding <tim.harding at gmail.com> wrote:
> I guess it all comes down to how you define exceptional.
> The argument put forward for find(params[:id]) throwing an exception in
> the first place is that if you're looking for a particular record and it
> isn't there then you probably had good reason to expect it to exist, there
> was a link to it or whatever. It would be pretty surprising if your app
> linked to a record that didn't exist. That's exceptional according to the
> Rails framework.
>
> If you try to find(:all) then you're looking for a set and an empty set is
> a normal kinda set, returning an empty collection is unexceptional.
>
> They're basically equating record not found to page not found here.
>
> Perhaps it all comes down to how your app is specified to handle record
> not found, if there's something actually useful you can do on RecordNotFound
> that will help the user then handle the exception where it is raised. If
> there are reasonable decisions you can take in each different instance then
> global exception handling isn't very useful.
>
> If you're working on a CMS and an :id actually represents a page then
> being able to declare what should happen to RecordNotFound, i.e.,
> presenting a 404 is actually remarkably useful and saves a whole lot of
> worry about letting things slip through the gap.
>
> What do you do to handle a record not found in your app?
>
>
> On Dec 19, 2007 4:50 AM, James Adam < james.adam at gmail.com> wrote:
>
> > I think we've talked about this before, but Rails 2.0 has taken a
> > stance so I thought it might be interesting to pick the "Best Minds In
> > London" (i.e. you filthy lot) about the use of exception handling as a
> > form of flow control.
> >
> > I'm talking about this:
> > http://almosteffortless.com/2007/10/08/graceful-404s-in-rails-20/
> >
> > Which is, to summarise, advocating throwing an exception when, say,
> > you can't find a particular record with that ID, and then letting some
> > Rails magic pick up the pieces and run a method accordingly.
> >
> > I'd always thought that exceptions shouldn't really be used for this,
> > although I don't have a particularly solid justification for this
> > belief. Am I wrong? What do you think?
> >
> > Actually, here's the quote, and I take issue with a different aspect
> > of it here too:
> >
> > "Lots of common exceptions would do better to be rescued at a shared
> > level rather than per action. This has always been possible by
> > overwriting rescue_action_in_public, but then you had to roll out your
> > own case statement and call super. Bah. So now we have a class level
> > macro called rescue_from, which you can use to declaratively point
> > certain exceptions to a given action."
> >
> > Surely "rescue_action_in_public" was only there to handle unforseen
> > catastrophic errors? It seems like massive overkill/folly for anyone
> > to try and use this to handle ActiveRecord::RecordNotFound, right?
> >
> > --
> > * J *
> > ~
> > _______________________________________________
> > Chat mailing list
> > Chat at lists.lrug.org
> > http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20071219/1091ca2b/attachment-0003.html>
More information about the Chat
mailing list