Re: Function Opinion

> Status is simple.  For each function there
> are two possible results.  Either it worked,
> or it didn't.  If it works, it returns a result.
> If it didn't work it returns an error code,
> and it's my job as programmer to
>determine why.

Sorry, I guess I should have included an example of what I was thinking.
It's this error code I'm thinking of.  There are degrees of error/status.
When opening a file, I might get an 'in use' error, and want to put the
program into a sleep/delay mode and try again to open it later.  Or I might
get a 'no object' error.  The calling program needs to distinguish between
these sorts of errors.

I can hard-code those definitions (0=OK, 1=resource busy, 2=no object, etc.)
into every related function that uses files, or I can use a /COPY member to
copy in a standard set of them into all modules that do file I/O.  In my
case, that would be the single service program and every calling program.
In the case of one function=one service program, that'd be every file
related service program and every calling program.

The day comes when I realise yet again (short memory!) that I forgot a
particular status/error code: 327=record locked.  In my case, I change the
/COPY member and the single service program to detect and report this new
error code.  Re-compiling the single service program is all it takes to
deploy that change.  If my calling programs do something like 'if read()<>0'
then none of them even need to change (ick!)  But presuming I have found a
particular program I want to detect this condition in, I just add the test
after the I/O and re-compile that one program.  Because I use binder
language, the signatures are all good and I can deploy my change with two
objects: the service program and the single calling program.

If I had many service programs and no binder language, I'd have to go find
all the service programs which _might_ need to be changed (read() and
update()?) and all the calling programs that use any of the newly compiled
service programs.  Then I get to recompile the lot and deploy them all.
Miss one and I'm having a Bad Day.  Especially since I work for a software
house and need to send my changes to many customers.

> If you're talking about error codes, (which obviously
> I don't use, but could if the necessity should arise) I
> would put the codes and their meanings in a separate
> file, that would be available via another
> function.

My function code looks like this

blah blah
... record is in use error gets trapped
eval returnCode=RCD_IN_USE
return

in the calling program, like this:

rc=read(customer)
select
when rc=RCD_IN_USE
... do delay thing
when rc=CUST_NOT_FOUND
... do the not found thing
blah blah

That's the sort of thing I was thinking about; especially having to add a
new code like NO_OBJECT_FOUND, which is easier to read than 'if rc=2'.
Well, it is to me, anyway!

I had no idea this thread would be so interesting, but it's good to hear how
others look at this problem of packaging code.
  --buck