L
Laura Stern
Guest
Re Marian's post on 9/26 at 14:26: Sorry Marian, but I'm now more confused than before! i.e., I'm not sure if we are in sync or not. I don't understand why you said that if we take out the comment about "the ones with error messages" that you like the solution. At the risk of repeating myself: Certain STOP conditions intrinsically have error messages associated with them. The STOP statement is not one of those. And I agree (with someone above; can't find who) I don't know if anyone actually uses this except for testing or experimenting. Nevertheless, it exists. The STOP conditions from STOP-AFTER or CTRL-C also have no error message. So only STOP conditions with errors can be associated with a P.L.StopError object, which implements P.L.Error. If there is no error message, it doesn't make sense to map the condition to an interface designed for giving you access to messages and message numbers. But we know people would still like to trap the STOP from a STOP-AFTER or a lock wait time-out, etc. So you can instead catch those by using a CATCH for P.L.Stop. (or some sub-class as a couple of people proposed). In these cases, there is no message, but you should be able to find out what caused the stop condition via a property of the P.L.Stop object (or by the class type if we use sub-classes).
Continue reading...
Continue reading...