retry does not work

[T. Onoma]

matz:

you rejected my rcr on garden saying that retry already does it. but it does not. maybe there's a trick to it? but i could not read your example b/c it was cut off by the < --you have to use &lt; [Aside: why hasn't this been fixed at garden? argghhh..]

so please show me how resume would work with retry here. here is the example again:

def resume_example(x)
begin
print x
x = x + 4
if x < 10
raise
end
print x
rescue
x = 10
resume # if retry -> 51014
end
puts
end
resume_example(5) # -> 510

thanks matz,
-t0

[ts]

>>>>> "T" == T Onoma <transami@runbox.com> writes:

T> you rejected my rcr on garden saying that retry already does it. but it
T> does not. maybe there's a trick to it? but i could not read your example
T> b/c it was cut off by the < --you have to use &lt; [Aside: why hasn't
T> this been fixed at garden? argghhh..]

Well the example was probably

def resume_example(x)
print x
x += 4
begin
raise if x < 10
print x
rescue
x = 10
retry
end
puts
end



Guy Decoux

[T. Onoma]

Guy Decoux:

> Well the example was probably
>
> def resume_example(x)
> print x
> x += 4
> begin
> raise if x < 10
> print x
> rescue
> x = 10
> retry
> end
> puts
> end

you have refactored my code to achieve the result. is all code so easily refactored?

def i_am_libaray_code
# this is a library call
# to be used in many differnt apps
# do not add user interface code!
raise SpecialWaring, "Warning, incoming!"
...
end

def resume_example(x)
begin
i_am_library_code
rescue SpecialWaring => e
puts e
resume
end
end

i can not refactor the lib call to conatin stdout, and i need a message from it about its status. perhaps there is another way to do this. if you know please tell!

-t0

[Yukihiro Matsumoto]

Hi,

In message "retry does not work"
on 03/11/20, "T. Onoma" <transami@runbox.com> writes:

|you rejected my rcr on garden saying that retry already does it. but it does not. maybe there's a trick to it? but i could not read your example b/c it was cut off by the < --you have to use &lt; [Aside: why hasn't this been fixed at garden? argghhh..]
|
|so please show me how resume would work with retry here. here is the example again:

Check the code carefully (note where "begin" is). It's not just
replacing resume with retry. "retry" jumps back to "begin".

|def resume_example(x)
| begin
| print x
| x = x + 4
| if x < 10
| raise
| end
| print x
| rescue
| x = 10
| resume # if retry -> 51014
| end
| puts
|end
|resume_example(5) # -> 510

def resume_example(x)
print x
x = x + 4
begin
if x < 10
raise
end
print x
rescue
x = 10
retry
end
puts
end
resume_example(5) # -> 510

matz.

[ts]

>>>>> "T" == T Onoma <transami@runbox.com> writes:

T> i can not refactor the lib call to conatin stdout, and i need a message
T> from it about its status. perhaps there is another way to do this. if
T> you know please tell!

Becuase you can't refactor the library, you *can't* use resume like you
want use it because you know nothing about the internal of this library



Guy Decoux

[Robert Klemme]

"T. Onoma" <transami@runbox.com> schrieb im Newsbeitrag
news:E1AMm57-0002fp-HX@odie.runbox.com...

> Guy Decoux:
>

> > Well the example was probably
> >
> > def resume_example(x)
> > print x
> > x += 4
> > begin
> > raise if x < 10
> > print x
> > rescue
> > x = 10
> > retry
> > end
> > puts
> > end

>
> you have refactored my code to achieve the result. is all code so easily

refactored?

>
> def i_am_libaray_code
> # this is a library call
> # to be used in many differnt apps
> # do not add user interface code!
> raise SpecialWaring, "Warning, incoming!"
> ...
> end
>
> def resume_example(x)
> begin
> i_am_library_code
> rescue SpecialWaring => e
> puts e
> resume
> end
> end
>
> i can not refactor the lib call to conatin stdout, and i need a message

from it about its status. perhaps there is another way to do this. if you
know please tell!

What strikes me is that you use "resume" in the rescue clause instead of
"retry". Is that on purpose or is maybe a simple misspelling the reason
for your frustration.

Kind regards

robert

[T. Onoma]

Guy:

> Becuase you can't refactor the library, you *can't* use resume like you
> want use it because you know nothing about the internal of this library

no, i wrote the library. ;) but i don't want interface code in it so i can resue it under differnt circumstances.

-t0

[ts]

>>>>> "T" == T Onoma <transami@runbox.com> writes:

T> no, i wrote the library. ;) but i don't want interface code in it so i
T> can resue it under differnt circumstances.

Then change it : your need of resume in this case, just means that your
library was badly designed


Guy Decoux

[Yukihiro Matsumoto]

Hi,

In message "Re: retry does not work"
on 03/11/20, "T. Onoma" <transami@runbox.com> writes:

|you have refactored my code to achieve the result. is all code so easily refactored?

Not all, but most.

Your "resume" makes exception handling much harder. With "resume",
every raise can be re-entered, that means programmers need to care
about re-entrance always.

So allowing new thing is not always a good thing.

matz.

[T. Onoma]

Hi matz,

thanks for reposting, someone should really fix that bug on ruby garden.

so Guy gave me same answer. i have problem with it. could you look at those and let me know? ( you probably already are \:)

-t0

[T. Onoma]

Guy:

> T> no, i wrote the library. ;) but i don't want interface code in it so i
> T> can resue it under differnt circumstances.
>
> Then change it : your need of resume in this case, just means that your
> library was badly designed

thats crap.

were taking about seperation of concerns --that's not bad design. i have a library i use for downloading files. i have a user interface script that uses the library. things happen in the library and if the user has set verbose more i should be able to report them to the user *without* having to write special esoteric message passing code.

sounds aweful dosen't it? come on, are you goating me?

-ts

[ts]

>>>>> "T" == T Onoma <transami@runbox.com> writes:

T> were taking about seperation of concerns --that's not bad design. i have
T> a library i use for downloading files. i have a user interface script
T> that uses the library. things happen in the library and if the user has
T> set verbose more i should be able to report them to the user *without*
T> having to write special esoteric message passing code.

You are raising an exception, this is, for me, different than sending
message to stdout

Guy Decoux

[T. Onoma]

matz:

> Your "resume" makes exception handling much harder. With "resume",
> every raise can be re-entered, that means programmers need to care
> about re-entrance always.
>
> So allowing new thing is not always a good thing.

worry? isn't that what testers are for ;)

okay, so maybe there could be an option put on raise to allow resuming?

just as an example of what this could do: tanaka is adding hook into open_uri to do progress reporting of download. to make it work you have to pass a lambda that acts on progress. but with resume you could raise a ProgressException(pos) and resume, which is much cleaner.

-t0

[T. Onoma]

> 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?

-t0

[Yukihiro Matsumoto]

Hi,

In message "Re: retry does not work"
on 03/11/20, "T. Onoma" <transami@runbox.com> writes:

| so Guy gave me same answer. i have problem with it. could you look at those and let me know? ( you probably already are \:)

I'm sorry; which is your problem? [ruby-talk:85791]?

In message [ruby-talk:85791], you wrote:

|were taking about seperation of concerns --that's not bad design. i
|have a library i use for downloading files. i have a user interface
|script that uses the library. things happen in the library and if the
|user has set verbose more i should be able to report them to the user
|*without* having to write special esoteric message passing code.

"resume" won't work well unless both your code and the user code know
each other (the user code must care that raise might resume; your code
must know how to fix up the exception cause). In that case, I think
you can make "retry" work, otherwise you can't make them work well
anyway.

matz.

[Yukihiro Matsumoto]

Hi,

In message "Re: retry does not work"
on 03/11/20, "T. Onoma" <transami@runbox.com> writes:

|just as an example of what this could do: tanaka is adding hook into open_uri to do progress reporting of download. to make it work you have to pass a lambda that acts on progress. but with resume you could raise a ProgressException(pos) and resume, which is much cleaner.

Sounds like exception abuse for me. You can use continuation if you
want to do something like that.

matz.

[ts]

>>>>> "T" == T Onoma <transami@runbox.com> writes:

T> so what other means are there? should a raise_message be added? or maybe
T> you are right. maybe my library is "badly designed", but if so then tell
T> me what would the alternative be that achieves such seperation?

svg% cat b.rb
#!./ruby

def send_message
warn "message"
end

$-w = nil

puts "before"
send_message
puts "after"

class A
def write(string)
puts "a nice message #{string}"
end
end

$stderr = A.new
$-w = true

send_message
svg%


svg% ruby b.rb
before
after
a nice message message
a nice message
svg%



Guy Decoux

[T. Onoma]

> "resume" won't work well unless both your code and the user code know
> each other (the user code must care that raise might resume; your code
> must know how to fix up the exception cause). In that case, I think
> you can make "retry" work, otherwise you can't make them work well
> anyway.

that is a good point, but the alternative seems to be passing proc or passing self. self seems like over kill, but passing proc is messy. no win situation here? perhaps this suggests another facility like raise but that does not halt execution. rather it moves up the call chain looking for a handler, if it finds one it executes, if not forget it, and then resumes execution. better RCR?

thanks,
-t0

[Yukihiro Matsumoto]

Hi,

In message "Re: retry does not work"
on 03/11/20, "T. Onoma" <transami@runbox.com> writes:

|that is a good point, but the alternative seems to be passing proc or passing self. self seems like over kill, but passing proc is messy. no win situation here? perhaps this suggests another facility like raise but that does not halt execution. rather it moves up the call chain looking for a handler, if it finds one it executes, if not forget it, and then resumes execution. better RCR?

It's called "coroutine". If you are going to write new RCR, I
recommend you to google it first.

matz.

[Robert Klemme]

"Yukihiro Matsumoto" <matz@ruby-lang.org> schrieb im Newsbeitrag
news:1069327343.081885.18914.nullmailer@picachu.ne tlab.jp...

> Hi,
>
> In message "Re: retry does not work"
> on 03/11/20, "T. Onoma" <transami@runbox.com> writes:
>
> |just as an example of what this could do: tanaka is adding hook into

open_uri to do progress reporting of download. to make it work you have to
pass a lambda that acts on progress. but with resume you could raise a
ProgressException(pos) and resume, which is much cleaner.

>
> Sounds like exception abuse for me.

Definitely! That's not an exceptional condition, but rather a case for
regular invocation of a callback.

> You can use continuation if you
> want to do something like that.

Isn't that a bit overkill? Hm...

robert