From: Gregory Brown <gregory.t.brown@...>
Date: 2008-10-05T00:19:20+09:00
Subject: Re: Is Assignment in a Conditional an Idiom?

On Sat, Oct 4, 2008 at 6:23 AM, Robert Dober <robert.dober@gmail.com> wrote:
> On Fri, Oct 3, 2008 at 10:18 PM, Gregory Brown
> <gregory.t.brown@gmail.com> wrote:
>> On Fri, Oct 3, 2008 at 5:16 AM, Robert Dober <robert.dober@gmail.com> wrote:
>>
>>> As is the rescue clause, I really would know more about why not to use it.
>>
>> It swallows all possible errors, not just the one you're banking on
>> running into if your object is nil.
> The fact that you know this makes it so usable.
> I like educational code and I dislike rules.
> I do not see why
>    x = @a["b"].split rescue []
> is bad code, only because
>    x = @a[some_method()].split rescue []
> is bad code.
> But there is no account for taste, see Rick I improve my idiomatic
> English thanks to you ;).

Personal experience only but I believe I've seen virtually every line
of code again in the form of:

 a rescue b

At the end of a long debugging session.  The reason is because even in
the simple case:

@a["b"].split rescue []

What you're trying to say is "If @a['b'] is nil, default to []"

But when you have

@a = nil,

this does not catch it.

When you have @a["b"] && !@a["b"].respond_to?(:split)

this does not catch it.

Instead, you lump three distinct failure cases into a single failure
condition.  If you can be absolutely sure that you really want it to
act that way in all those cases,
go for it.  But you know, if I'm refactoring and I change @a to @apple
throughout my app, I sort of want lines that still reference @a to
break.

When I refactor code that once returned a string to return an object
that maybe requires something like foo.text to get at the string, I
want to know about the old places where I'm calling foo.split.

I think this is a case where people have found something that allows
them to be a little bit lazy, and then tried to pretend that it fits
another good pattern (trying something and then rescuing some
unambiguous exception, rather than futzing around with respond_to?),
when it's really a totally different animal.

Your code is far from educational, it is misleading, and the rules you
talk about are really behaviors, and if you want to assume that you
could treat all behaviors the same way, go for it, and have fun
debugging.

-greg

-- 
Technical Blaag at: http://blog.majesticseacreature.com | Non-tech
stuff at: http://metametta.blogspot.com