On Sun, 20 Jun 2021, at 19:08, Paul Gilmartin wrote:
> On Sun, 20 Jun 2021 18:08:39 +0100, Jeremy Nicoll wrote:
> >> >
> >> I see. I'd be inclined to code the repetitive part of that as a loop.
> >
> >There'd be no gain in converting the 8 separate named-for-what-they do
> >variables
> >into stem variables if that's what you mean, unless one also defined _bfe,
> >_ssn etc
> >as separate subscripts. The vars are in fact the parameters to the
> >function, originally
> >set via
> >
> I was imagining somethint like (untested; no stems):
> List = "ssn ssx stm wcn wcx wln wlx wld"
> do while List<>""
> if \datatype("f!ce_"L, "W") then f!ce_err = L value( "f!ce_"L )
> "not a whole number"
> /* etc. */
> end
Clearly it needs to be a bit more complicated than that as you're going to have
to use value() to extract the values of each f!ce_xxx variable, but I get what
you
mean. I just don't think it's any clearer than the select code was.
> Do you want to report every error, or leave after the first one?
First one. The whole function is pretty unlikely to be mis-called so the checks
were only really to prevent something like
f!mn_chk = "func_jn_chk_encp"(f!mn_optns,"L", 2, -1, "", 1, -1, 2, -1,
2)
having its whole parameter list slipped sideways. (There are other checks
made on the parms but making sure that almost all of them are whole nos
is required before testing the relationships between them.)
I have in the past rather than using just numbered elements of stems eg
thing.1 = "The problem here is"
thing.2 = 21
thing.3 = 25
typically defined
_errpfx = 1 ; _xcoord = 2 ; _ycoord = 3
then
thing._errpfx = "The problem here is"
thing._xcoord = 21
thing._ycoord = 25
and then in procedures that also have to access parts of the "thing."
stem passed a literal containing "_errpfx _xcoord _ycoord" and run
a loop at the start of the procedure to set local vars to 1,2,3 etc.
(In fact I use the loop in the mainline code too, to make sure that
the named subscript vars have the same values everywhere.)
> >> SIGNAL? I suppose it's OK here.
> >
> >Thank-you, that's big of you. It's a branch to the end of the function, so
> >that there's only one place where control returns to the caller.
> > ...
> >I only use signal in error handling / immediate exit/return situations.
> >
> And its value is in branching to common termination code before EXIT
>
> I'm as compulsive about avoiding SIGNAL as you are aboutt singlee EXIT.
> I might even wrap everything in an outer DO just so I could use LEAV.
Single point of return makes it a lot easier to be certain that every return
has expected contents. A lot of my functions will eg return either an
error message or a result, as
"ERROR: whatever the message is" or
"REPLY: 17 20 Fred"
and in the latter instance it's important to make sure that all elements of
a multi-part return value are there. That often means quite a lot of code
between the start of the return-setting code and the actual "return"
statement. It's also a place that often has logging and/or debug code
in it, so better to make sure it runs on every call.
--
Jeremy Nicoll - my opinions are my own.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
