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

> "Lloyd Zusman" <ljz / asfast.com> schrieb im Newsbeitrag
> news:m3fz7711m6.fsf / asfast.com...
>>
>> [ ... ]
>>
>> Why not just use the 'sync' module that is already being utilized in
>> the program?  i.e. ...
>>
>>   $fileThreads = [].extend(Sync_m)
>
> Oh, I overlooked that.  Is that std Ruby?  (Monitor and Mutex are)

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


>> Thanks.  But how about this slight variation?  Since I had exit(rtail),
>> I could just do it this way ...
>>
>>   # at the bottom of the script ...
>>   begin
>>     rtail
>>     result = 0
>>     # or if I want:    result = rtail
>>   rescue Exception => e
>>     $stderr.puts("!!! #{e}")
>>     result = 1
>>   end
>>   exit(result)
>
> I prefer this:
>
>   # at the bottom of the script ...
>   begin
>     exit rtail
>   rescue Exception => e
>     $stderr.puts("!!! #{e}")
>     exit 1
>   end
>
> because it's more robust if you change your mind and want to do different
> things (like not exiting).  It keeps information more local.  Maybe this is
> a habit I got from Java because compilers can warn you if you put the exit
> (or return for methods) into their respective neighborhood and forget one of
> them.

??? In your case, the problem you mentioned (forgetting exit or return)
seems _more_ likely, since you explicitly code 'exit' in two places.  In
my version, it only appears once.  Using your construct ...

  # at the bottom of the script ...
  begin
    exit rtail
  rescue Exception => e
    $stderr.puts("!!! #{e}")
    ###exit 1
    accidentally_forget_to_exit()
  end

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)


> It will be even clearer if you break this code up into multiple method
> invocations.  Then you'll have methods like:
>
> begin
>   File.open("foo.txt") do |io|
>     # IO is open here
>     # do more stuff
>   end
> rescue Errno::Enoent => e
>   $stderr.puts "ERROR: ..."
> rescue OtherError => e
>   ...
> end

Yes, I often do that.  It just seems like overkill in my small app.


> Reusing a global (!) for the current error message looks irritating to
> me.

Yep.  That's why I said that I don't like it.  I gave that example to
show how undesirable it is.


> Then you can do
> $prog = File.split($0)[1]
>
> Advantage of File.split is that it's platform independend.  Only introduce
> platform dependencies that are really necessary - that might make your life
> much easier in the future.

Good point.  I have now replaced the $0.sub(...) call with this:

  File.basename($0)

I believe that it's better than the File.split version, because it is
giving me exactly what I want: the basename of the file.  That makes the
code more self-documenting; and besides, I already use File.basename
elsewhere in the code for the same purpose.


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