[LRUG] Exceptions as a flow control mechanism

[David A. Black]

Hi --

On Wed, 19 Dec 2007, James Adam 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?

I think there are two issues here: first, whether to raise exceptions
in such-and-such circumstances; and second, what Rails should do if
and when you do.

I'm not opposed to an exception being raised for an unfound record,
since that really is a condition under which normal execution can't go
on (as opposed to one of multiple branches of normal execution). I
don't think it's an out-and-out case of using exceptions just for flow
control; that would be something more like:

   begin
     print "Your name: "
     name = gets.chomp
     raise unless MEMBERS.include?(name)
   rescue
     MEMBERS << name
   end

where the exception mechanism is basically a substitute for an if
structure.

Of course you could wrap all attempted find operations as
conditionals, but I think it's reasonable for a failed find to raise
an exception. If that's true, then the question is whether this magic
method thing is a good way to handle it. I'm not sure how I feel about
it. It seems like it could grow pretty out of control if you decided
to handle different exceptions differently. I haven't checked into it,
but if the method receives the exception as an argument, that might
help keep down the number of handlers.

So I'm not sure I agree that the basic mechanism is massive overkill
for a case like this, though I could imagine it not scaling very
prettily.


David

-- 
Training for 2008!
Ruby on Rails training by David A. Black/Ruby Power and Light, LLC:
    * Intro to Rails, New York, NY, February 4-7 2008
    * Advancing With Rails, New York, NY, February 11-14 2008
Hosted by Exceed Education. See http://www.rubypal.com for details!