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.
(quote_responses || ).count > 0 && rqstate.eql?(“submitted”)
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.