This is terrible style and is strictly forbidden in our codebase. In the example below, probably the programmer thought that an exception always meant that quote_responses was nil instead of an array, and that nil should be treated as an empty array. That works fine... until another source of errors comes along. What if the interface for arrays changed such that count was no longer a valid method, so that this function always returned false? Instead of an obvious exception and a quick fix, the code would just return the wrong answer all the time. (We actually had this sort of problem when switching Rails versions.) Or maybe the name of the rqstate variable changed, and the "undefined variable" exception resulted in this code returning false - same problem.
Something like this is much better. Handle the particular situation that is causing exceptions, so that real problems will remain visible. def receipt_available (quote_responses || []).count > 0 && rqstate.eql?("submitted") end Save exception handling for cases where it is really needed. If there's no way to avoid the exception, and you have a way to recover from the exception, then catch only that very specific type of exception. You can also have a high-level exception handler for the entire application that takes care of reporting uncaught exceptions so that they can be fixed. On Thu, Nov 5, 2015 at 3:47 PM, wbsurf...@yahoo.com <wbsurf...@gmail.com> wrote: > > I was reading some ruby one liners. The rescue style seems to make it easy > to write short pieces of code, but it feels like I am forcing an error and > then just ignoring it in some cases. I guess I am an older programmer and > was never encouraged to write this sort of code, but do most people feel > like this is good style ? > > def receipt_available > quote_responses.count > 0 && rqstate.eql?("submitted") rescue false > end > > obviously if code had alot of possible errors to recover from you > wouldn't do that > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rubyonrails-talk+unsubscr...@googlegroups.com. > To post to this group, send email to rubyonrails-talk@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/rubyonrails-talk/d9c52162-6942-4f29-a2f1-2287af28ae8b%40googlegroups.com > <https://groups.google.com/d/msgid/rubyonrails-talk/d9c52162-6942-4f29-a2f1-2287af28ae8b%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- ------------------------ Eric Lavigne Director of Software Development MCNA Systems elavi...@mcna.net Mobile: (352) 871-7829 ------------------------ CONFIDENTIALITY NOTICE: This electronic message transmission from MCNA Dental is intended only for the individual or entity to which it is addressed. This e-mail may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication and attachments is strictly prohibited by the standards set forth in the HITECH Act of 2009. If you received this e-mail by accident, please notify the sender immediately and destroy this e-mail and all copies. Thank you. ------------------------- 200 W Cypress Creek Rd Fort Lauderdale, FL http://mcna.net -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-talk@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CADoJS-vVM0-AExoo5yowEEJnx5m41EXYhCyY-6AiZBUu0NHPjg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.