Progress Programming Tips

PPT-19  Emulating exceptions in Progress - Part 2 of 3

Tip:

[Warning - long topic continues]

The final piece in the exception puzzle is how to react to the
action code being returned from the error handler.  Lets
examine some different situations.

1.  The error was really a warning or information level problem
so the proper handling has already happened with the message
management in the error handler.  The action code is continue
with normal processing.

2.  The error signals that this procedure or block cannot
complete its activity as desired and must terminate.  However,
the whole application is not at risk.  The action code is undo
and leave current processing block.  This includes an internal
procedure needing to return error rather than finish its task.

3.  The error signals that the whole application is at risk and
needs to exit as gracefully as possible.  The action code is stop all
processing and exit.

The first option requires no action and can just continue
processing normally.  The second and third situations map
directly to error conditions that Progress has support for in
its block handling capabilities.  This leaves us with a simple
partial solution and difficult to impossible full solution.

Simple, partial solution -

Rather than reinvent the wheel why not just raise the appropriate
Progress condition, expecting proper block handling statements to
exist to control the resulting behaviour?  This is an acceptable
answer, and unfortunately probably the only realistic one available
today.  This is a partial solution though as it does not handle
carrying the error context up through levels to be resolved but rather
requires immediate resolution by being translated into a real
condition.  This is not to say that proper block handling can't be
written to manage levels of response but that all that propagates
upward is the Progress condition, not any real error context like we
were managing.

After all that effort what we really have is a well managed,
standardized way of handling error messages and error checking
that requires the same attention to block structuring that any
error handling in Progress does.

Not bad mind you, but not as elegant as real, named, exceptions.

Difficult to Impossible, full solution -

To get to the full solution we need to manage the error context
up through multiple levels of condition processing.  Managing the
availability of this information is very doable, where we lose the
advantages is in the constant checking required to make action
decisions.  Take as an example a procedure returning error.  How do
you know in the caller to review the error and make another action
decision?  If every action decision was an error then you could raise
the error condition, make the error handling block retry, and test in
the retry.  As you can tell we have lost the limited impact portion,
and are starting to introduce side effects with such a plan so
feasibility is dropping rapidly.

Conclusion -

The end of this story is not very satisfying - no holy grail of
error processing etc. yet is a typical result when trying to
build in language level features second hand.  On the positive
side trying to reach the goals has provided some techniques to
standardize and improve error handling within the bounds that
Progress provides.  Also having tried this exercise and knowing
the roadblocks prepares you to review what a new version of
Progress provides, with an eye towards a final solution.

Even without complete success part three will be a working
example of these techniques in action.

Wisdom:

It is not foolish to try for the unreachable, just to expect
that you will reach it.


Rod Gaither                  | rdg@worldinfo.com
World Information Systems    | (910) 333-2580  Voice
Greensboro, NC               | (910) 333-2584  Fax