Re: MCH1201 (Rcvr too small) on an _if_ statement???

Scott,

Like you, I'd define any error-handler which provides the "An unexpected
error occurred" as being badly-designed! However, that has nothing to do
with *PSSR's specifically...

However, I would also consider a bad design as someting where a hard-error
can cause a low-level relatively technical (i.e. meaningless to an end user)
message to be displayed to the user:

1. Maybe they have the option to dump, maybe not.
2. Maybe they use the dump option, maybe not.
3. Maybe they report the error to IT Admin, maybe not.

As you pointed out, with a *PSSR you can protect your users from meaningless
error messages, whilst also ensuring that dumps happen automatically, people
get notified etc.

The thing about a return code is that it *can* tell you a lot. Sometimes it
can tell you whether the processing failed fully or partially, whether it
succeeded, but that there are other issues etc. It can also tell you
*how*the processing failed (if you allow for multiple return code
values, as I
sometimes do.

If we're talking about code where the caller ignores the return code, that's
not a problem with the concept of return codes - it's a problem with the
caller being badly written. The only times I ignore return codes are for
'unimportant' procedures (which write debug data to a job log, for instance)
where the procedure is bulletproof. And even then, I sometimes check it
anyway.

Rory

On Mon, Jul 28, 2008 at 12:40 PM, Scott Klement
<rpg400-l@xxxxxxxxxxxxxxxx>wrote:

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

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.