 |
|
Current group: bit.listserv.tsorexx
massive boilerplate inclusions (was : functions returning boolean ... or failing ...)
|
|
| | From: | Fenner, Jim | | Subject: | massive boilerplate inclusions (was : functions returning boolean ... or failing ...) | | Date: | 17 Jan 2005 23:29:40 -0800 |
|
|
 | An idle comment on the "functions returning boolean ... or failing ...)"
example:
One COULD retain some sort of clarity by calling an internal routine
called i_iplsoon, which then calls external iplsoon
if i_iplsoon() then ...
deep in the in the bowels of your program is the real call:
i_iplsoon :
(do stuff)
xv=iplsoon() /* call external Rexx */
/* handle error condition - copied from Mr Bridges post*/
if left(xv,1)='!' then
else /* proceed using xv */".
(do more stuff, ie error checking)
return xv /* if errors happen, we might exit by SIGNAL */
Points to ponder:
-----------------
- If you don't own ipsloon external rexx, this helps you code around any
weaknesses
- If you do own it, you can go the extra mile and paste lots of error
checking into it as well (it seems to be a theme that we're never safe
anywhere without lots of error checking)
- If everyone had a Rexx compiler we could do helpful INCLUDES I
believe. But we don't in our installation.
- Related gripe:
---------------
With Rexx one has to code EVERYTHING oneself - with Java, one gets a
vast class library of tested routines and WORKING examples for free.
Will IBM ever distribute a vast library of Rexx routines at *any* price
that would save us all this work?
It's like the old joke about "You'll have to make your own bed" and then
you get handed a hammer and nails!
- I am starting to wonder if massive boilerplate inclusions in EVERY
rexx are the only way to create reliable REXX code bases.
I say this after seeing many polished examples from (eg) Mr Rob Zenuk,
and also Frank Clarke.
Maybe we all ought to just individually pay Mr Zenuk for a licence to
his entire library, the fruit of decades of experience, and toss out
almost everything else we have written ... :-(
Wed end up with 500,000 lines of Rexx in our toolbox instead of 100,000,
but at least we would all share the same 500,000 lines ...
Regards
Jim
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-REXX@VM.MARIST.EDU] On Behalf
Of Carroll, Bill
Sent: 11 Jan 2005 09:57
To: TSO-REXX@VM.MARIST.EDU
Subject: Re: functions returning boolean ... or failing ...
Bob thanks for your input... I have been returning 0 1 or -1 from the
subroutine and letting the SIGNALs in the Calling program catch the
error.
I may continue to do this... but for clearer error messages... QUEUE one
to
the stack for the calling REXX to use it it's handling of the error. I
was
just hoping to find a really clean way to do it.
Thanks for the options.
Bill
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-REXX@VM.MARIST.EDU] On Behalf
Of
Bob Bridges
Sent: Friday, January 07, 2005 12:44
To: TSO-REXX@VM.MARIST.EDU
Subject: Re: functions returning boolean ... or failing ...
Yeah, but if 0 (false) is a valid return, how is the calling routine to
know the difference between FALSE and a failure?
I can think of two ways to deal with this...no, three:
a) Have the subroutine handle the error all by itself, by abending the
program if there's a problem, or by contacting the user itself, or with
your SIGNALs, or something. This is often unsatisfactory, but after all
it's the method used with the built-in functions -- they return a value
if
at all possible, but otherwise abend the program ("improper call to
routine...").
b) Have the calling program test the rc for non-Boolean values. For
example, in subroutines that are supposed to be silent to the user, I
often signal an error to the calling routine by an error code preceded
by
a bang ("!"). So if the routine passes back an expected value, it's
good,
but if it returns "!43" it means something went wrong. If you use this
technique, you'd have to say "xv=iplsoon(); if left(xv,1)='!' then /*
handle error condition */; else /* proceed using xv */".
c) Write Boolean subroutines only in cases that are so simple there is
no
error condition to be caught.
The problem with option B is that it ignores the whole point, ie the
simplicity and convenience of being able to say merely "if
iplsoon()...".
But then, if you have to consider possible error conditions, the
simplicity was illusory, wasn't it?
---
Bob Bridges, robertbridges@discoverfinancial.com, 224 405-0811
rhbridg@attglobal.net, 847 520-1684 xt 243
/* Influence is not to be confused with corruption. Influence can get
you
to the head of the line to get your driver's license; corruption is when
you fail the test but get the license anyway. -William F Buckley,
2004-09-17 */
"Woodlyn, Sjon O."
2005-01-07 11:06
To: TSO-REXX@VM.MARIST.EDU
cc:
Subject: Re: functions returning boolean ... or failing
....
If it fails, shouldn't the error processing in IPLSOON() set the bool
value
to false? The whole point in boolean is that it return either
true/false
(a
failure being false).
-----Original Message-----
From: Carroll, Bill [mailto:william.carroll@EDS.COM]
Sent: Friday, January 07, 2005 8:58 AM
I have some confusion on the best way to go.... as far as coding
functions
that return boolean true or false. For instance.
If I have a function called : IPLSOON and I call it like this:
IF IPLSOON() THEN
.... do IPL notification stuff
ELSE
.... continue monitoring
My question is... How do I handle a failure in a function that returns
boolean values... where anything other than true(1) or false(0) returned
becomes an error in the calling REXX.
I typically use the following skeleton code for error routines and
adjust
them according to the specific implementation.
/* rexx */
Arg Whatever .
Signal On Failure
Signal On Syntax
Signal On Novalue
/* add code here */
EXIT
/*-------------------------------------------------------------------*/
/*- ERROR ROUTINES -*/
/*-------------------------------------------------------------------*/
Failure:
PARSE SOURCE . EXECTYPE EXECNAME EXECDDN EXECDSN . EXECENV EXECADSP .
Say "Error in" EXECNAME " - Failure occured on source line" Sigl
Say SOURCELINE(Sigl)
Call Cleanup
Exit(???)
Return
Syntax:
TRC = RC
PARSE SOURCE . EXECTYPE EXECNAME EXECDDN EXECDSN . EXECENV EXECADSP .
Say "Syntax Error in " EXECNAME '-' ERRORTEXT(TRC) '- LINE' Sigl
Say SOURCELINE(Sigl)
Call Cleanup
Exit(???) /* USE -1 for sub prog. actual abend code for driver */
Return
Novalue:
PARSE SOURCE . EXECTYPE EXECNAME EXECDDN EXECDSN . EXECENV EXECADSP .
Say "Error in" EXECNAME " - Novalue used on source line" Sigl
Say SOURCELINE(Sigl)
Call Cleanup
Exit(???) /* USE -1 for sub prog. actual abend code for driver */
Return
Cleanup:
/* do program specific cleanup here */
Return
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX
****************************************************************
IMPORTANT
The information transmitted is for the use of the intended recipient only and may contain confidential and/or legally privileged material. Any review, re-transmission, disclosure dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited and may result in severe penalties. If you have received this e-mail in error please notify the Privacy Hotline of the Australian Taxation Office, telephone 13 28 69 and delete all copies of this transmission together with any attachments.
****************************************************************
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX
|
|
|
| | |
|
 |