Re: [U2] [UV] Programmatic Verification of Globally Cataloged Subroutine

Good points. My view is that it is usually not a matter of whether the 
failure should be catastrophic.  It's usually a matter of who should be 
in in control of the catastrophe.  If you call a object that bombs, the 
caller will never know why because control never returns to the caller. 
    With this technique, if you don't get a validated response, you can 
certainly choose 'go on'  in the main program but you chould also choose 
to make it a catastrophe.   The point is that your main program regains 
control after it provokes failure and can choose what to do with the 
failure.  As you point out, it might just log the error but it could 
logoff, or throw some other hissy instead of moving forward.  Note that 
the capture variable 'result' will contain the failure message.  That 
could be parsed to to whatever...

*For example:
...
*   IF INDEX( result, \%%validated%%\, 1) THEN
      CALL userSubroutine(foo, bar...)
    END ELSE
      message = \Call to \:userSubroutine:\ failed with this error: \:result
      message:= \So, we aborted on port \:@USERNO:\.  Sorry it didn't 
work out and thanks for all the fish.\
      emailTo = \[email protected]\
      emailSubject = \Houston we had a problem on port\: @USERNO
      CALL emailAdmin( emailTo, emailSubject, message, status)
      CRT message
      GOSUB makeACatastopheOutOfIt
    END
...

makeACatastopheOutOfIt:
    ABORT
RETURN

Bruce Decker
Blue Prairie, Inc.
720.733.0459
http://www.bluepinc.com

On 1/30/2014 11:03 AM, Robert wrote:
> Nice technique. My first reaction was "why would you want to not let a 
> subroutine failure be catastrophic?!". I could see where it could 
> allow data to get scrambled. Let's say an decryption routine unable to 
> decrypt so the encrypted data gets sent back exactly the same.
>
> But then I could see where this would create resiliency with some 
> non-critical function that could be fixed after the fact, like a 
> cross-referencing subroutine which sets up cross-references, just to 
> add feature.
>
> Your technique allows the failure and keeps moving forward, with 
> hopefully an error log entry so someone could fix it.
>
> Almost like an error message from the system when you don't initialize 
> a variable to zero, so it does that for you and gives you a nastrygram 
> in the process, but it doesn't effect operation (in many cases).
>
> Thanks for the tip.
>
> Robert Norman
>
>

_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users