On Mon, 21 Apr 2008 21:18:17 -0500, Paul Gilmartin <[EMAIL PROTECTED]> wrote:
>... >My technique for picking up the pieces after a failure is to >improve the code so that it no longer fails. A nonzero return >code is not a failure. Reference to an uninitialized variable >is a failure. I couldn't agree more (as if anybody cares). And trapping and error can assist in that (but obviously not with techniques like you quote later in your posting.) >... >I have _never_ coded a SIGNAL. Partly hangover from the 3 decades >ago "GOTO considered harmful" days; ... I think abuse of ITERATE and LEAVE to be a much milder crime. But that maybe from my also shunning SIGNAL. I've used SIGNAL only for condition trapping. I guess I have not read this part of the fine manual for many years. I see that the ON condition statements can contain either SIGNAL or CALL. I guess you can CALL the condition-handling routine and return past the failing statement. Sort of a REXX ESTAE. I'm not sure I would want to try that in most cases. (CALL ON HALT could be down right mean! Maybe those are the situations where HE will kill and exec but HI will not.) >... >But a "SIGNAL ERROR" with no handler would provide much the >traceback and termination I desire. I'd just have to accept >no longer being able to say "I have never coded a SIGNAL." Ah! THERE is what I wasn't seeing - the ability to raise a condition when you aren't using a condition handling block. Yup, that's tough to do without a way to programmatically raise the condition. Pat O'Keefe ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
