From: Lloyd Zusman <ljz@...>
Date: 2004-08-01T21:31:47+09:00
Subject: Re: Forward references?

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

> "Lloyd Zusman" <ljz@asfast.com> schrieb im Newsbeitrag
> news:m33c383xee.fsf@asfast.com...
>>
>> [ ... ]
>>
>> [ ... ] Putting simple subsidiary routines in one or more separate
>> files often complicates installation and maintenance.
>
> True.  It's a tradeoff: it seemed to me that having prototypes was a
> paramount requirement of you.

Well, actually, what's important (or at least desirable) to me is not
prototypes in and of themselves, but rather, just to have the main body
of the code near the top of the file.


> [ ... ]
>
> Very nice!  [ ... ]

Thank you.


> [ ... ] I like especially the documentation.  Some remarks from cursory
> glancing though:
>
> require 'monitor'
> # My list of threads.
> $fileThreads = [].extend MonitorMixin
> # later
> $fileThreads.synchronize do
>   # do stuff with $fileThreads
> end

Why not just use the 'sync' module that is already being utilized in
the program?  i.e. ...

  $fileThreads = [].extend(Sync_m)


>  - You are using exit a bit too much IMHO, especially since you have
> "exit(rtail)" but rtail invokes exit, too.  Usage of exit reduces
> reusability of code and thus I would limit it to the to level of the script,
> something like
>
> begin
>   # do MAIN stuff
>   exit 0
> rescue Exception => e
>   $stderr.puts e
>   exit 1
> end

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)

... and then raise exceptions every other place where I was using 'exit'.


>   And within the rest of the script I'd use exceptions.  Patterns like this
> are inferior
>
>     begin
>       block = self.read(testsize)
>     rescue
>       return false
>     end
>     # further code that works with block
>
> Instead put all the code for the clean case into the block or leave the
> rescue completely out here and handle the exception on a higher level.  That
> makes things much easier.

Yes, that's a good approach in many cases, and I will do so in those
instances.  However, in a few places, I have different kinds of 'rescue'
responses for different steps within the flow of control.  Look at
$fileReadProc in my program, for example.  I want my error message to
distinguish between "unable to open", "unable to stat", "invalid
device", etc., and I want to use my own error message text for each of
these instances.  I don't see how to avoid a series of short
begin/rescue/end blocks in this case.

Hmm ... well, I could do this, but I don't like it:

  $errorMessage = 'unknown error'
  begin
    $errorMessage = 'unable to open'
    # open the file
    $errorMessage = 'invalid device'
    # do stuff that fails if the item is not a file
    $errorMessage = 'unable to stat'
    # do stat-related stuff
    $errorMessage = 'message for next likely exception to be raised'
    # ... etc. ...
  rescue
    begin
      f.close
    rescue
      # file may or may not be open when exception occurs
    end
    output([nil, "!!! #{$errorMessage}: #{item}]")
    abortMyself()
  end

In the case I have shown here, I prefer the smaller begin/rescue/end
blocks, even though that's more verbose.  It will be clearer to future
maintainers.


>  - There is File.split:
>
> # old: $program = $0.sub(/^.*\//, '')
> $dir, $program = File.split $0

Yes.  I'm just in the habit of doing this myself, especially when I
don't want the '$dir' part.


> I hope, that was not too frustrating... :-)

No, not at all.  Everything is much appreciated.



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