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
