rescue clause

[Patrick Doyle]

[Note: parts of this message were removed to make it a legal post.]

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

 

[Sandro Paganotti]

[Note: parts of this message were removed to make it a legal post.]

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.

 

[Stefan Lang]

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?

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

 

[Patrick Doyle]

[Note: parts of this message were removed to make it a legal post.]

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