Re: Proper way to return a string

Paul van Delst <Paul.vanDelst@xxxxxxxx> wrote:

Richard E Maine wrote:

For me, returning an error code is a reason to avoid using a function.

if I have a procedure in which an error is "detectable" (say, via STAT,
IOSTAT, or simply checking the validity of input arguments) then I always
do:

errStatus = MyFunc(inarg1,inarg2,...,outarg1,outarg2,....)
IF (errStatus /= SUCCESS) THEN
...handle error...
END IF

rather than,

call MySub(inarg1,inarg2,...,outarg1,outarg2,...,errStatus)
IF (errStatus /= SUCCESS) THEN
...handle error...
END IF

My reason for doing so is only because I find the function call form
easier to parse when I'm looking at source code.

I used to do it your way many years ago, but I stopped and switched to
the subroutine way. There were 2 reasons for my switch

1. Questions about strict standard conformance. Yes, there is
disagreement on this. But there is no disagreement at all on whether the
subroutine call is ok. So I go conservative.

2. Really the driving factor in my case.... While *I* could read the
code fine in either case, I consistently found that my users could not.
I had no end of support problems from users who expected, for example,
that a function whose purpose was to read some data would that data as
its result. This was particularly true when I elided the temporary
variable used to store the function result and wrote something like (not
the real names, but illustrative), depending on whether the return was
logical or integer (I used both at times)

if (.not. read_some_data(..., some_data)) then
... handle error
end if

or

if (read_some_data(..., some_data) /= ok) then
... handle error
end if

People were forever asking me what this code did. Even though I
documented it (extensively), they just had trouble in reading it or
grasping the style. (Obviously, these people were not refugees from C; I
regard this as very much a C style, but some of this was in the days
before C was much evident at all in scientific apps).

When I switched to

call read_some_data(...., some_data, error)
if (error) then
... handle error
end if

or the equivalent integer case. I no longer got the support calls.

As I said, I could read it either way. I did slightly like the function
call just because it could be fewer lines of code (and didn't need the
extra temp variable). But the difference in readability by my users was
large and evident.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
.