"Robert Klemme" <bob.news / gmx.net> writes:

> "Lloyd Zusman" <ljz / asfast.com> schrieb im Newsbeitrag
> news:m3vfg2tsvl.fsf / asfast.com...
>>
>> [ ... ]
>>
>> Sync_m has been around ever since 1.6.x, and it's excplicitly mentioned
>> in the Pickaxe book (on page 120, the last line of the "Condition
>> Variables" section of Chapter 11, "Threads and Processes").  You can see
>> the code in RUBYINSTALLDIR/lib/sync.rb
>
> Oh, once again learned something new.  But as far as I can see it's only
> mentioned at this single location - no examples no additional
> explanations.

Yes, sync.rb (containing Sync_m and Synchronizer_m) is not mentioned or
documented anywhere else that I can find.  I'm not sure where I stumbled
upon it ... I probably saw it used in someone else's code and then
investigated it.  Although the mutex and monitor classes also can work
here, I prefer Sync_m in this case because its name reflects the exact
use to which I am putting it: synchronization.


> [ ... ]
>
> Yeah, but you'll soon recognize that the program does not exit.  While
> it's more difficult ro recognize that it exits in both cases but you
> wanted it to do something else in once case IMHO.  Maybe it's a matter of
> taste or my usage to Eclipse's excellent Java support which gives you
> compile error messages and warnings that help a lot.  Of course, Ruby is
> not compiled... :-)
>
>> If I want to do something other than exiting, then I can do the
>> following with my construct:
>>
>>    # at the bottom of the script ...
>>    begin
>>      result = rtail
>>    rescue Exception => e
>>      $stderr.puts("!!! #{e}")
>>      result = 1
>>    end
>>    ###exit(result)
>>    do_something_other_than_exiting(result)
>
> Yeah, but that treats both cases (ok and error) the same and you have to
> make a distinction in do_something_other_than_exiting().  That's typically
> bad; it's better to have separate methods that handle each case
> individually because methods then do just *one* thing and not two.  Of
> course, if you do the same in every case it's reasonable to have a single
> method.

Yes.  Here I always want to exit.  If I wanted to do something different
on exit and on error, I would structure this code snippet differently.


>> [ ... ]
>>
>> Yes, I often do that.  It just seems like overkill in my small app.
>
> Personally I prefer that kind of "overkill" over other strategies.

Adding a number of small methods would decrease maintainability of my
particular program, IMO.  That is not true in general, and I indeed do
this on other kinds of projects.  However, think that it does apply in
this case.

But there is plenty of room to differ here.


I refactored the code even more, based on our discussions and some ideas
of my own.  If you're interested, I can privately email you the latest
version.


-- 
 Lloyd Zusman
 ljz / asfast.com
 God bless you.