"Lloyd Zusman" <ljz / asfast.com> schrieb im Newsbeitrag
news:m3vfg2tsvl.fsf / asfast.com...
> "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

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.

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

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.

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

Personally I prefer that kind of "overkill" over other strategies.

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

Ah, ok.

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

Yeah, much better.  I didn't think of File#basename.

Kind regards

    robert