How defensively should you code your procedures?

I am just, finally, stating to re-write an old "standard work with"
shell style program and have created my first module (actually 2) and
created my first service program from one module and a real honest to
goodness program from the other which links to the service program. And
with a minor hiccup (an "indicator field" gets type checked at compile
time and originally a "*like define *IN Afield" was used as a short cut
to create single char fields (1)) it all works OK.

However, given the following procedure:
<BEGIN>
/define SvcMod
/include qincprsrc,StdHSpec
/include qincprsrc,SvcDspFmt


*-------------------------------------------------------------------------
* Procedure name: SflPageStatus
* Purpose: Returns a more descriptive SFLEND decorator
showing
* when a previous subfile page exists as well as
the.
* current pages SFLEND status.
* Returns: SflPageStatus
* Parameter: SflRRN => RRN of subfile record.
* Parameter: SflPag => Size of a page of subfile records
* Parameter: EOF => File EOF status

*-------------------------------------------------------------------------
P DspFmt_SflPageStatus...
P B EXPORT
D DspFmt_SflPageStatus...
D PI 3A
D SflRRN 5P 0 CONST
D SflPage LIKE(SflRRN)
D CONST
D EOF 1N CONST

*-------------------------------------------------------------------------

* Local fields

/free

select;
when %rem(SflRRN:SflPage) <> 0; // Not last record on subfile
page.
return ' ';
when SflRRN > SflPage and EOF;
return '-/ ';
when SflRRN > SflPage;
return '-/+';
when eof;
return ' / ';
other;
return ' /+';
endsl;

/end-free

P E
<END>

I can see that there is the potential for an error condition where the
field SflPage is zero. Now this example is overly simplistic, if there
was a zero the program would throw an exception - problem found!

If, however, a different problem existed that did not throw an exception
but instead worked producing the wrong results I could see an advantage
of coding a test then issuing an escape message and using all the
advantages of the built in message handling or using some form of return
code.

(I personally like/prefer the idea of messages over return codes, there
is always the possibility of someone not testing a return code where as
an exception is so in your face it can't be missed and if not dealt with
by the coder will not be missed by the user! There is also the
possibility of coding a "message information data structure" and using
that to condition if a return of error(s) are passed back or if an
escape message is issued in the same way IBM codes API's for larger more
complex procedures.)

But for the first example specifically, and procedures in general, would
you code a specific test and issue/report some kind of error? Would you
always test everything?

In the above example, not only could I test and throw an error based on
the SflPage - "USR1024 Subfile page value must be greater than
zero" (Actually I have just realised that if the number were negative it
would work; as I typed the message it was originally going to say "can
not be zero") but I could also test the value of SflRRN.

If I test the values by coding defensively it would mean they were
tested for every call of the procedure which could mean the same tests
performed thousands of times within a program which obviously is a
performance hit.

My gut says:
1) Always test everything you can, throw exceptions on testing errors
unless you also code some form of return status.
2) Only code a return status if the tests are complex and/or you want to
return warning/logical type errors and true exceptions.
3) I am still leaning towards "exceptions" always throwing escape
messages even when warnings and logical errors are returned in a status
code because if they exist someone really mucked up badly in the calling
code; its not a logical style error "Customer invalid" but a real
exception "customer number should never be less than zero" or even
"customer number will roll over."


(1) I can live with better type checking on indicators at compile time,
the specific code in the original source used a tri-state - blank for
not initialised and *ON/*OFF for state (roll up/Down, blank meant no
roll key pressed... it made sense at the time.). But! The runtime does
no such checking, I can move a character field not containing "1"/"0"
into an indicator and it doesn't complain during the move or when
tested, however the result can be unpredictable. It also changed how
CLEAR worked, originally it cleared the indicator defined field (blanked
it) but then with RPG IV changed to "0"ing it.