Re: What's the proper way to "reraise" in a CLP?

On 6/21/2017 10:11 AM, Nathan Andelin wrote:

If your goal is for CLPs to receive messages from Python, I'm just
suggesting that you come up with a solution that doesn't involve using
program message queues. The term "program" in this context is something of
a misnomer, because every procedure in a call stack has a message queue
associated with it. The API for "sending" program messages requires that
you specify the call-stack level that you want to send to. Likewise, the
API for receiving messages, also requires that you specify the call-stack
level that you want to receive from. That is a problem, in my opinion.

There /are/ many options, but that doesn't mean that the work must
necessarily be complex. I recommend and use RCVMSG *SAME, SNDPGMMSG *PRV.

Called programs don't necessarily know what procedures at what call-stack
levels may be receiving their messages.

Why do they have to? If a message happens that can't be handled,
percolate it higher, to the caller, whatever it might be.

And the call-stack entries that may
need to monitor for messages, are never really assured whether messages
will be sent to their message queue, or to one preceding it, or to one
seceding it.

It's my hard-learnt experience that /all/ call stack entries need to
monitor for messages. In the days of yore, when programs mostly ran in
batch in a stately, well-ordered procession, if one rolled over, it was
a good thing that a white message popped up and the job went into MSGW.
A programmer would be called, the process debugged, the cause
discovered, and the fix made. The message would be answered and the
planets would roll in their orbits once more.

But now that we're all doing more webby stuff, it's imperative that none
of the programs in that process _ever_ hang on a MSGW. I don't
personally do any web-facing work, but I do write stored procedures,
UDTs, UDTFs, and other glue that the front end calls upon to make the
web side work. If any of those programs hang in MSGW, it won't be long
before hundreds of jobs are hanging in MSGW. The web side will have no
idea that something has gone casters up, and the end user will be
sitting and waiting for a response that may be hours in the making.

So now, I make it a habit to start coding with the error handling at the
fore. It's really not optional any more.

The idea of having callers implement code to receive messages and percolate
those they don't know how to handle, seems like a kludge to me.

How else can my programs deal with unexpected errors?