I'd see it as a Ruby's failure that the proper check is against DRY.
DRY is most egregious when the duplicated components are far apart from each other. (And hence harder to spot!) Duplicating things right next to each other is Mostly Harmless, and it's always the next best thing if you can't think of the final refactor.
The problem with the rescue modifier is that it lumps all types of errors
into one relatively blunt tool. A rescue(Type) modifier would really
help, and a ?. operator (like Groovy's) would resolve one of the most
common cases for a rescue modifier.
--Ken
···
On Mon, 02 Mar 2009 09:36:10 -0500, Gregory Brown wrote:
On Mon, Mar 2, 2009 at 3:18 AM, Michal Suchanek <hramrach@centrum.cz> > wrote:
2009/3/2 Gregory Brown <gregory.t.brown@gmail.com>:
But please, don't use this technique. It creates huge debugging
nightmares.
I'd see it as a Ruby's failure that the proper check is against DRY.
Agreed, but the costs of the elegance of using rescue as a conditional
modifier stack up fast in any moderately complex system.
-greg
--
Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology. http://www.iit.edu/~kbloom1/
it'd remove the debugging issue. However, this does force the
interpreter to do a whole lot of extra work raising and rescuing an
error unnecessarily.
Groovy's ?. looks about right in terms of what we really want most of
the time rescue is used as a conditional modifier.
In the past, I've implemented this as:
class Object
def try(sym, *args)
return if nil?
send(sym, *args) if respond_to?(sym)
end
end
then, you get:
a = obj.try(:capitalize) || 42
But there are obviously some other limitations here...
-greg
···
On Mon, Mar 2, 2009 at 10:38 AM, Ken Bloom <kbloom@gmail.com> wrote:
The problem with the rescue modifier is that it lumps all types of errors
into one relatively blunt tool. A rescue(Type) modifier would really
help, and a ?. operator (like Groovy's) would resolve one of the most
common cases for a rescue modifier.