2010/2/25 Phil Smith III <li...@akphs.com>
......
> Another great use for SIGNAL (and one that your rules do admit to) is for
> error exits. I hate code like this:
>
> address command 'somecmd'
> if rc <> 0 then do
> say 'That was an error, rc='rc
> exit rc
> end
>
> Far better IMHO is:
>
> address command 'somecmd'
> if rc <> 0 then signal Error
>
> This keeps the mainline more compact and readable, and it's pretty clear to
> the reader that "Hey, we're going somewhere to handle the error and we ain't
> comin' back"!
>
> We now return you to the actual thread on SFS.
>
> ...phsiii
>
I agree with the "use Signal sometimes", in cases where one will not return,
it is more clear indeed. But, the example above "if rc<>0 then signal
Error" isn't very practical: you cannot pass parameters. So I have a Call
to my errorexit: routine. The name of the called routine makes it clear to
the reader that one will not return from there.
if rc<>0 then call errExit rc,'Something was wrong','Please try again'
.......
ERREXIT: /* general errorexit routine */
parse upper source . . myname .
do i=2 to arg() /* give errormessages (if any) */
say myname':' arg(i)
end
exit arg(1)
I guess we devoted some chapter to it in our selfstudy Telecourse:
http://www.vm.ibm.com/download/packages/descript.cgi?TCVM1
--
Kris Buelens,
IBM Belgium, VM customer support
