I partially agree with you, David.
I would suggest, however, that a *PSSR is a good place to insert code
that does a dump, prints the job log, and e-mails the whole she-bang to
a developer or support person who will be able to solve the problem.
Though, in my environment, where I can do a WRKACTJOB and view the
user's job log, a hard-halt is very close to providing the same level of
useful information... it's just a little less user-friendly.
However, the problem I have with Rory's suggestion is that a return code
doesn't necessarily tell you anything. Many times programmers using a
*PSSR in this fashion will put up a message that says "Unexpected error
occurred" which makes it very hard to determine what the actual error was.
Worse, the calling routine can easily just ignore the return code, and
not report the error -- in which case, you have the same problem as
having a *PSSR that does nothing but end the program normally. You end
up with no notion that anything failed, and no diagnostics to use to
solve the problem.
IMHO, when an unexpected error occurs, the DEFAULT action should be to
stop the program. i.e. if the caller doesn't take any action to prevent
the program from stopping, then the program should stop. A return code
implements the exact opposite. The caller can CHOOSE to examine the
return code and take action, but if nothing is done, the default action
is for the program to continue running unaware of the problem.
Thus, I like to have a *PSSR in the controlling program -- the one that
represents a control boundary within the application -- and I like to
have that *PSSR do a dump and dump the job log and notify the
appropriate people.
I like subprocedures in service programs or secondary modules to simply
fail if they're going to fail (as a rule -- though there are certainly
exceptions to that rule) Let the caller MONITOR if they don't want it to
stop their process. If nothing else is done, eventually the error
propigates to the *PSSR at the control boundary, and then it takes
control and handles things appropriately.
Sorry if this is hard to understand -- it's a difficult thing to explain.
David Gibbs wrote:
Rory Hewitt wrote:
Evil? Really? Why?
Mainly because, in a normal software development environment (not tools, not utilities, etc), the kind of errors that get trapped by *PSSR should not be trapped because they represent programming errors. Yes, a hard halt is jarring for the user ... but it's a strong impetus to get the error fixed.
Additionally, the error is trapped globally and unconditionally.
Furthermore ... they are way too *EASY* to abuse ... case in point: a *PSSR routine that's just RETURN or SETON LR/RETURN.
Do you also think MONITOR-blocks are evil?
In general, no ... although I don't think they are as useful as they could be. Their usage is quite localized ... so it's very difficult to put a monitor block in and have it effect other code.
david
midrange.com
