Re: Some database discussions...

On 5/18/2017 11:01 AM, Nathan Andelin wrote:

few RPG programmers write code to detect errors, much less handle
them.

I think we should clarify that "errors" in the context of this discussion
means various types of messages placed in various call-stack message
queues, which may be sent by IBM i components and applications, which are
normally accompanied by a *ESCAPE type message, which raises an "exception"
that leaves a JOB in a *MSGW status by default.

Given the number of possible variations in this architecture, is it any
wonder that application developers would rather write code to prevent
"errors", rather than try to deal with them?

I invoke QMHRCVPM/RCVMSG *LAST and subsequently *PRV with the message
key got from *LAST. Is there another way for the system to raise an
exception message? Or another way for a program to do something with
them? I'm specifically thinking about 'number of possible variations'
and drawing a blank.

If your search-for-errors routine doesn't *REMOVE them after finding them,
the same messages will show up in the next search-for-errors call. It seems
to me that one's search-for-errors routines would be prone to failure.

With respect to *REMOVE, *LAST finds the last one, regardless of how
many there are in the job log. Generally speaking it seems a good idea
to me to remove the messages I handled, but I can always re-send
exceptions as *INFO if that would be useful.

With respect to searching for errors, I, the programmer, do not control
how the admins on my system will set up security (for one example). I
don't want a web app to sit in MSGW with no response at all to the end
user, so I pretty much already need to trap errors, and once trapped, do
something with that information. So I'm not searching for errors per se
- I'm receiving the exception messages and handling all of them.

So rather than search for errors, I classify them as they come in. If
the error is expected (like RI violation) then manipulate the UI to be
nice to the end user. If the error is unexpected (user storage
allocation limit reached) give a generic 'Call IT and report CPF9876!'
at the UI and gracefully terminate.

If the application design requires it, it may be appropriate to trap
exception messages, and throw diagnostic and exceptions up the stack for
the caller to handle it. This architecture might have several code
paths; 'normal', 'undo', 'restore', etc which would be directed from the
top.