I guess it all comes down to how you define exceptional.<div><br class="webkit-block-placeholder"></div><div>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.
</div><div><br class="webkit-block-placeholder"></div><div>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.</div><div><br class="webkit-block-placeholder">
</div><div>They're basically equating record not found to page not found here.</div><div><br class="webkit-block-placeholder"></div><div>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.
</div><div><br class="webkit-block-placeholder"></div><div>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.
</div><div><br class="webkit-block-placeholder"></div><div>What do you do to handle a record not found in your app?</div><div><br class="webkit-block-placeholder"></div><div><br><div class="gmail_quote">On Dec 19, 2007 4:50 AM, James Adam <
<a href="mailto:james.adam@gmail.com">james.adam@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I think we've talked about this before, but Rails 
2.0 has taken a<br>stance so I thought it might be interesting to pick the "Best Minds In<br>London" (i.e. you filthy lot) about the use of exception handling as a<br>form of flow control.<br><br>I'm talking about this:
<br><a href="http://almosteffortless.com/2007/10/08/graceful-404s-in-rails-20/" target="_blank">http://almosteffortless.com/2007/10/08/graceful-404s-in-rails-20/</a><br><br>Which is, to summarise, advocating throwing an exception when, say,
<br>you can't find a particular record with that ID, and then letting some<br>Rails magic pick up the pieces and run a method accordingly.<br><br>I'd always thought that exceptions shouldn't really be used for this,
<br>although I don't have a particularly solid justification for this<br>belief. Am I wrong? What do you think?<br><br>Actually, here's the quote, and I take issue with a different aspect<br>of it here too:<br><br>
 "Lots of common exceptions would do better to be rescued at a shared<br>level rather than per action. This has always been possible by<br>overwriting rescue_action_in_public, but then you had to roll out your<br>own case statement and call super. Bah. So now we have a class level
<br>macro called rescue_from, which you can use to declaratively point<br>certain exceptions to a given action."<br><br>Surely "rescue_action_in_public" was only there to handle unforseen<br>catastrophic errors? It seems like massive overkill/folly for anyone
<br>to try and use this to handle ActiveRecord::RecordNotFound, right?<br><font color="#888888"><br>--<br>* J *<br>  ~<br>_______________________________________________<br>Chat mailing list<br><a href="mailto:Chat@lists.lrug.org">
Chat@lists.lrug.org</a><br><a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br></font></blockquote></div><br></div>