Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!fernwood!uupsi!cmcl2!lanl!cochiti.lanl.gov!jlg
From: jlg@cochiti.lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: Decent FORTRAN books?
Message-ID: <25205@lanl.gov>
Date: 6 Jun 91 16:48:42 GMT
References: <1991Jun5.161838.4436@cunixf.cc.columbia.edu> <1991Jun6.031122.27876@jato.jpl.nasa.gov> <50082@ut-emx.uucp>
Sender: news@lanl.gov
Organization: Los Alamos National Laboratory
Lines: 35

In article <50082@ut-emx.uucp>, jwe@che.utexas.edu (John W. Eaton) writes:
|> [...]
|>    Excessive use of the alternate RETURN feature can lead to a messy
|>    logic flow between subprograms.  Its use should be reserved for
|>    exception handling...
|> 
|> Unfortunately, he doesn't point out that the same effect can be
|> achieved (in a clearer way, IMHO :-) by simply using a single extra
|> integer parameter, say ERROR, and setting its value before returning.

I disagree.  Any user of Fortran should know what an alternate return
means and an IF statement in the same context would be no clearer (in
fact, it would be less clear in the case for which alternate return was
intended - see below).

Further, the IF statement is much less efficient: you are going to
make a test for error in the caller when the subroutine has already
made such a test.  Further, you will be making a test which fails
99.99% of the time (assuming that you really are using alternate
return only for exception handling).  This means that your test is 
doubly wasted: it's seldom true (so it wastes time) and it actually 
obscures the _usual_ flow of control through your code.

Exception handling is a problem for which _everyone_ agrees that
non-local control flow is the _natural_ way to handle it.  Ada 
exceptions don't explicitly test at each level, you "raise" an
exception and the currently active handler (wherever that is)
get control.  Even C has setjump/longjump (a very clumsy but 
effective mechanism).  Nobody wants their code strewn with 
constantly interspersed testS for conditions that hardly ever
arise (and which the explicit IF test, when successful, would
either return or GOTO anyway - so it's still non-local even
with the explicit tests).

J. Giles