From: Robert Klemme <bob.news@...>
Date: 2005-11-07T18:32:11+09:00
Subject: Re: programming best practices

swille wrote:
>> But the way you've written it, rc is always false.  Did you mean true
>> in the first line? :-)
>>
>> Also, it seems a little bit like you've got two error-reporting
>> systems going on.  Maybe you could combine them:
>>
>>    def login
>>      perform action
>>    end
>>
>>    begin
>>      login
>>    rescue
>>      ...
>>    end
>>
>> etc.
>>
>
> Ah, yes, that was a typo.  My example possibly wasn't the greatest...
> I couldn't think of exactly when I had used it last in Ruby.  It's
> actually something I've been using in Java quite a bit because I've
> been writing interfaces into JavaScript and there's no way (in
> JavaScript) to handle the exceptions from Java, so I use a boolean
> return value.  I decided at some point that I really like the
> aesthetics of it.  After a colleague questioned that behavior in
> another context though, I thought twice about whether it was a good
> idea.  Basically, I suggested he use a boolean return value to a
> method and he said something to the effect that it would be more
> proper to return int-based return codes because "some_method true?"
> didn't sound right.  I wondered if maybe I was going to regret not
> going to college :O)

<soapbox>
IMHO using int's as return values is as bad as using boolean return values
in a language that has exceptions.  Exceptions are a far more elegant way
of handling errors and also often code will be shorter and cleaner.  One
of the reasons for this is that you can throw an exception somewhere deep
down in an application or lib and catch it several layers above - at the
level where it makes most sense.  If you want to do that with boolean /
int return values you'll have checking and returning code in all
intermediate layers - this is bloated, ugly and unflexible.
</soapbox>

Kind regards

    robert