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.
