From: Patrick Doyle <wpdster@...>
Date: 2008-10-11T00:42:48+09:00
Subject: Re: rescue clause

------=_Part_103849_4739212.1223653507762
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

>
>
> The the first rescue clause and the SystemExit in the second clause
> can be removed without changing the semantics of the code.
>
> As a sidenote, something being popular does not necessarily
> mean it should be used as a model for good Ruby code.
> Sometimes the techniques used only make sense in a
> historical context.
>
> Stefan
>
> In order to shorten my email, I left out the rest of the code, which reads:

      rescue Exception => ex
        # Exit with error message
        $stderr.puts "rake aborted!"
        $stderr.puts ex.message
        if options.trace
          $stderr.puts ex.backtrace.join("\n")
        else
          $stderr.puts ex.backtrace.find {|str| str =~ /#{@rakefile}/ } ||
""
          $stderr.puts "(See full trace by running task with --trace)"
        end
        exit(1)

Because the code continues on to rescue Exception (which is the ancestor of
all exceptions), the code does need to rescue SystemExit separately (and
before, I believe) Exception.

Is there a historical reason why the second rescue clause contains
SystemExit and OptionParser::InvalidOption.  I understand your point about
what makes a good model for Ruby code.  In my case, having used makefiles
for decades, and having been quite comfortable with them (most of the time),
I am looking at rake and saying "what's in it for me?"  So far, the answer
has been, "Oh, that's cool!  This feature and that feature certainly would
make my life easier.  Hmmm... I wonder how (s)he did that?"  at which point
I start to explore.

Having the historical "proto_rake.rb" file and seeing the power of that
simple script, and seeing to where it has evolved at this point in time, is
also educational.

--wpd

------=_Part_103849_4739212.1223653507762--