Forum: Ruby rescue clause

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Ed437e52d8d6720308720e7e678f3e6d?d=identicon&s=25 Patrick Doyle (Guest)
on 2008-10-10 15:53
(Received via mailing list)
I have been looking at the source code for rake (as you can probably
tell
from my previous questions), in an attempt to study a reasonable sized
Ruby
application and see what I can learn from the exercise.  I've come
across
something that looks like it could be an innocuous typo in the code, or
it
could be doing something that I just don't understand.  Here is the code
snippet:

    def standard_exception_handling
      begin
        yield
      rescue SystemExit => ex
        # Exit silently with current status
        exit(ex.status)
      rescue SystemExit, OptionParser::InvalidOption => ex
        # Exit silently
        exit(1)
      end
    end

I am curious as to why SystemExit shows up in 2 different rescue
clauses.
Is that a typo?  Or is something else going on?

--wpd
0df4a6c75caf1bd9b01d2dcbfb085ee4?d=identicon&s=25 Sandro Paganotti (Guest)
on 2008-10-10 17:06
(Received via mailing list)
The difference seems to be in that ' OptionParser::InvalidOption ' token
but it's the first time I saw a begin-rescue block of this kind.
40613e55d7082e5f08429dfb50d0680e?d=identicon&s=25 Stefan Lang (Guest)
on 2008-10-10 17:26
(Received via mailing list)
2008/10/10 Patrick Doyle <wpdster@gmail.com>:
>      rescue SystemExit => ex
>        # Exit silently with current status
>        exit(ex.status)
>      rescue SystemExit, OptionParser::InvalidOption => ex
>        # Exit silently
>        exit(1)
>      end
>    end
>
> I am curious as to why SystemExit shows up in 2 different rescue clauses.
> Is that a typo?  Or is something else going on?

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
Ed437e52d8d6720308720e7e678f3e6d?d=identicon&s=25 Patrick Doyle (Guest)
on 2008-10-10 17:46
(Received via mailing list)
> 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
This topic is locked and can not be replied to.