<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div>Agreed with Tim.</div><div><br class="webkit-block-placeholder"></div><div>To add another example, I'm working on an API for a Flex client, and having centralised exception handling is extremely useful, since I need to render the exceptions as special objects so that they are picked up by Flex. In fact, it's so useful I've even implemented a little patch to ActiveRecord (which I need to remember to submit!...) that allows me to make the find_by_xyz... methods also throw an exception when no record is found (by adding a ! after the method name). This way all the 'record not found' exceptional cases are dealt with in a centralised, DRY, user-friendly way.</div><div><br class="webkit-block-placeholder"></div><div>Basically, you have a flow of steps in your controller. They depend on a number of objects being located. You have two options to deal with objects not found:</div><div><br class="webkit-block-placeholder"></div><div>1) the old, exception-less way of peppering your code with multiple if statements</div><div>2) the modern, effective way: write the code as it should work and let it throw exceptions when something goes wrong</div><div><br class="webkit-block-placeholder"></div><div>Once seen from this perspective, it makes a lot of sense, imho, to make it easy to centralise that exception handling.</div><div><br class="webkit-block-placeholder"></div><div>Also worth bearing in mind - the main reason why Exceptions are usually discouraged for flow control is because they are expensive to throw and catch. This is a problem when you're using an exception to control the flow of something small, like a loop. E.g., in Java:</div><div><br class="webkit-block-placeholder"></div><div>try {</div><div> Iterator it = array.iterator();</div><div> while (obj = it.next()) {</div><div> // do something</div><div> }</div><div>} catch (NoSuchElementException e) {</div><div> // let flow continue</div><div>}</div><div><br class="webkit-block-placeholder"></div><div>Using exceptions for this kind of flow control is discouraged because the exception handling takes a lot more time than the typical iterator loop.</div><div><br class="webkit-block-placeholder"></div><div>However, when you're looking at an HTTP request to a database-backed web server, the typical latency being in hundreds of milliseconds, the fact that the exception costs an additional 0.2ms to generate compared to creating a quagmire of if statements is irrelevant... You could thrown an exception in every single request and probably barely see the difference.</div><div><br class="webkit-block-placeholder"></div><div></$0.02></div><div><br class="webkit-block-placeholder"></div><div>Daniel</div><br><div><div>On 19 Dec 2007, at 12:22 19 Dec 2007, Tim Harding wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">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><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">_______________________________________________</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Chat mailing list</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a></div> </blockquote></div><br></body></html>