Ruminations

ruby-talk
1

I was looking at “Ruby in a Nutshell” on Amazon’s site and came across this in the Introduction on page 3:

begin
f = open(path)
rescue
puts "#{path} does not exist."
exit 1
end

Concerns:

  • What if the file exists, but the open uncovers some other condition. The problem has been misdiagnosed;
  • The “routine” has more than one exit. This violates the “one entry, one exit” rule of structured programming.

Comments?

2

I was looking at “Ruby in a Nutshell” on Amazon’s site and came across this
in the Introduction on page 3:

begin
f = open(path)
rescue
puts “#{path} does not exist.”
exit 1
end

Concerns:

  • What if the file exists, but the open uncovers some other condition. The
    problem has been misdiagnosed;

Correct, it should rescue a specific error, like Errno::ENOENT.

  • The “routine” has more than one exit. This violates the “one entry, one
    exit” rule of structured programming.

The snippet is out of context, so your conclusion is unjustifiably harsh :slight_smile:

Gavin

···

From: “Ted” ted@datacomm.com

3

I’ll start by commenting on the “one entry, one exit” rule. It arose in
the bad old days of assembler programming.

After all, how many OO languages do you know where it is possible to
have multiple entries to a routine? When I was taught VAX Macro one of
the “techniques” taught was to have a register bitmask that also
evaluated to a useful instruction. That way you could use the same
address for a JSR (Jump SubRoutine) and for a CALL. Really clever
developers also managed to jump into the middle of a subroutine, do
something useful and then jump elsewhere before reaching the return
statement. Needless to say, drawing a structure programming flowchart
for this code was really, really difficult. Maintaining said code was
even worse:-)

Modern OO languages by comparison, only have 1 way of entering a
routine, so early exit does not have anywhere near the problems that
assembler programmers were able to cause. Indeed, it is common to have
multiple exits. For example, Martin Fowler’s book Refactoring talks
about the use of Guard clauses which explicitly encourages multiple
returns (exits).

http://www.refactoring.com/catalog/
replaceNestedConditionalWithGuardClauses.html

So my take on this is that while some of the old structured programming
rules are still useful, we need to reevaluate all in the light of
modern programming paradigms.

“Reinterpreting your experiences is very important in times of change.
The reason is that as things change, we need to see if what we learned
in the past is still applicable and relevant.” - Chapter 5, Questioning
XP … Pete McBreen

Pete

···

On Saturday, December 7, 2002, at 10:24 PM, Ted wrote:

  • The “routine” has more than one exit. This violates the “one
    entry, one exit” rule of structured programming.

Comments?

Pete McBreen, McBreen.Consulting , Cochrane, AB

Author, “Software Craftsmanship The New Imperative”
Winner of 2002 SD Productivity Award

Author: “Questioning Extreme Programming”
Addison-Wesley (c) 2003

4

Well, the key is the page number. It is just fourth brief example of Ruby
code in the book and it should just show that Ruby has exception support.
Nothing more. As I write articles about programming from time to time I know
that you simply can not start with full-featured examples. Otherwise you
risk readers stop reading before they really start.

Dalibor Sramek

···

On Sun, Dec 08, 2002 at 02:24:17PM +0900, Ted wrote:

I was looking at “Ruby in a Nutshell” on Amazon’s site and came across this in the Introduction on page 3:
Comments?

–
Dalibor Sramek “In the eyes of cats, all things belong to cats.”
dali@insula.cz

5

Hi,

begin
f = open(path)
rescue
puts “#{path} does not exist.”
exit 1
end

Concerns:

  • What if the file exists, but the open uncovers some other condition. The problem has been misdiagnosed;

The message should have been something like “open failed for #{path}”.

  • The “routine” has more than one exit. This violates the “one entry, one exit” rule of structured programming.

I don’t care about that principle. It’s no good.

						matz.
···

In message “Ruminations…” on 02/12/08, “Ted” ted@datacomm.com writes:

6

Or at least print the actual exception, which will tell you why the open
failed. I’m willing to give Matz a break, though. I owe him one :-).

···

On Sun, 8 Dec 2002 16:31, Gavin Sinclair wrote:

From: “Ted” ted@datacomm.com

I was looking at “Ruby in a Nutshell” on Amazon’s site and came across
this

in the Introduction on page 3:

begin
f = open(path)
rescue
puts “#{path} does not exist.”
exit 1
end

Correct, it should rescue a specific error, like Errno::ENOENT.

7

I agree with you that multiple exits should not be eliminated as a
rule. Often, my code uses multiple exits. However, I would note that
the refatoring link is using a language where the form of the return
data is static.

Because the return type is not fixed in Ruby, we need to make a little
more judicious use of multiple exits. At the very least, you should
think carefully about returning objects that are different along
different exit paths. For instance, I would try to avoid code like
this:

def multiexit(choice)
case choice
when :1
return [1,2,3]
when :2
return File.new(‘/tmp/blah’)
when :3
return nil
end
end

My example returns wildly different objects, but subtly different
objects might be even harder to debug given multiple exits.

-alan

···

On Sun, Dec 08, 2002 at 03:12:29PM +0900, Pete McBreen wrote:

Modern OO languages by comparison, only have 1 way of entering a
routine, so early exit does not have anywhere near the problems that
assembler programmers were able to cause. Indeed, it is common to have
multiple exits. For example, Martin Fowler’s book Refactoring talks
about the use of Guard clauses which explicitly encourages multiple
returns (exits).

Catalog of Refactorings
replaceNestedConditionalWithGuardClauses.html

So my take on this is that while some of the old structured programming
rules are still useful, we need to reevaluate all in the light of
modern programming paradigms.

–
Alan Chen
Digikata Computing
http://digikata.com