[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: retry does not work

T. Onoma

11/20/2003 12:58:00 PM

robert:

thanks robert, that's basically what i decided to do. your code is nice and clean to. i like that.

but you know. it strikes me as funny that its thought a good idea to implement nested chains of handlers for errors but not for message passing. it seems like a natural fit to me. but when ever i bring it up i get all sorts of nay nays. what so bad about this idea? i think it would be a very powerful tool. i agree that resume should be automatic for this purpose, and a seperate command should exist. i don't what to hurt the poor little raise command. i'm not that bad! ;)

i may try to implement a way to do it.

later,
-t0


>
> "T. Onoma" <transami@runbox.com> schrieb im Newsbeitrag
> news:E1AMmpA-000682-J5@odie.runbox.com...
> > > You are raising an exception, this is, for me, different than sending
> > > message to stdout
> >
> > okay, i grant you that was not the intention of raise when designed. but
> a rose by any other name....
> >
> > so what other means are there? should a raise_message be added? or maybe
> you are right. maybe my library is "badly designed", but if so then tell
> me what would the alternative be that achieves such seperation?
>
> class Downloader
> attr_accessor :state_reporter
>
> def dowload(url)
> read_bytes = 0
>
> # open conn
>
> while( chunk = io.read( 1024 ) )
> read_bytes += chunk.length
> # write bytes to file
> self.state_reporter && self.state_reporter.call(url, read_bytes)
> end
> end
> end
>
> d = Downloader.new
> d.state_reporter = proc {|url, bytes| puts "read #{bytes} from #{url}"
>
> d.download 'http://foo/bar'
>
> You get the picture...
>

>
>
>

1 Answer

Robert Klemme

11/20/2003 2:23:00 PM

0


"T. Onoma" <transami@runbox.com> schrieb im Newsbeitrag
news:E1AMoNZ-0006k6-6g@fetch-bak.runbox.com...
> robert:
>
> thanks robert, that's basically what i decided to do. your code is nice
and clean to. i like that.

Thanks!

> but you know. it strikes me as funny that its thought a good idea to
implement nested chains of handlers for errors but not for message
passing.

The pattern usually used for distributing messages is Observer, i.e., you
have some event emitting item and others can register to receive these
events. I'm not sure what your idea of "nested chains of handlers" is
exactly and why it is best suited for this situation.

> it seems like a natural fit to me. but when ever i bring it up i get all
sorts of nay nays. what so bad about this idea? i think it would be a very
powerful tool. i agree that resume should be automatic for this purpose,
and a seperate command should exist. i don't what to hurt the poor little
raise command.

The problem is that you wanted to (ab)use exceptions for this. Exceptions
have a totally different purpose and don't fit well for a notification
mechanism other than exceptional notifications, i.e. situations where the
normal flow of control can't be resumed.

In fact, I don't see any reason to jump *out* of a context just to emit an
event. Instead jumping *into* another context (by issuing a method call)
is perfectly ok. And that's how event distribution typically works.

> i'm not that bad! ;)

Can we trust you on this...? :-)

robert