From: Lyndon Samson <lyndon.samson@...>
Date: 2005-11-08T07:45:38+09:00
Subject: Re: programming best practices

On 11/7/05, Robert Klemme <bob.news@gmx.net> wrote:
> Lyndon Samson wrote:
> > On 11/7/05, Robert Klemme <bob.news@gmx.net> wrote:
> >> 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
> >
> > Well if you were really against Exceptions you could allways use
> > continuations to do this more elegantly than nested returns.
>
> I'd be curious how an exception equivalent behavior with continuations
> would look like.  ATM I have the impression that it'll be far more
> complex...
>
Sorry, I meant deeply nested method calls returning one-by-one up the
call stack being replaced with Continuations, not replacing
Exceptions.



> Kind regards
>
>     robert
>
>
>


--
Into RFID? www.rfidnewsupdate.com Simple, fast, news.