I don't believe that it's
pretty sure a CANCEL of the whole cohesion is going to happen just because I
send a PREPARE_INFERIORS. I may be sending many such PREPARE_INFERIORS over a
period of hours or days and not make a choice until much later as to how to
end the cohesion. Or perhaps I've misunderstood what you
meant.
PF 2: The application
logic has gone wrong - it's lost track of what inferiors it actually
has. I would most strongly advise writers of transactional applications
to make the error path of their code cause the cancellation of anything
it can cancel, rather than try to barge their way through. And probably
even more so for writers of intermediate abstraction layers (which has
less idea what's going on and ought to be even less likely to get its table in
a twist)
PF: My
concern was to avoid forcing an implmentation to scan through the list to
check, when there is very little use that can be made of the warning, and when
the warning shouldn't happen anyway.
I
disagree that there is little that can happen when a warning occurs. Whatever
called PREPARE_INFERIORS (whether directly or via many layers of abstraction)
had better expect that such an error can occur and to be able to deal with it.
What I'm saying is that we can say at our level that "nothing will have
prepared" if such an error occurs and that gives the higher-level abstractions
and business logic a better footing from which to deal with the error than
would otherwise be the case IMO.
There
ought to be an exception catcher, certainly. And if that really wants to carry
on, we have the mechanisms to interrogate the actual status (remember that
inferiors can go prepared spontaneously anyway). But why must the decider
implmentation be requried to produce a well-defined result to what was a
garbled instruction. The application (or abstraction) code is bugged.
Peter