J
jquerijero
Guest
1. Is it a good thing that a CATCH for Progress.Lang.Error (etc.) can catch STOP conditions associated with error messages? Is this what you would expect, or would you rather have to code explicitly to catch any STOP condition? >>> A Progress.Lang.Error derived class for STOP with error should be fine. If Progress.Lang.Error is intended to be the base class of all ABL related errors, I would expect Progress.Lang.Error to catch all trappable errors. Having a separate base class for STOP with no message is OK, although I think it is still superfluous (see next answer). 2. Do you see an issue in that STOP can possibly get caught before it would have before, which is either never caught or at a DO ON STOP higher up the call stack? >>> It might be a good information to know if the error is just a STOP condition, but I really don't see a difference in handling a standard error (or even STOP with message) and STOP condition. If I really need to bubble up an error that is already caught, I think implementing a re-THROW (THROW without parameter) that can be included inside the CATCH is fine. 3. Is there anything else that OpenEdge Engineering should consider? >>> A more consistent THROW.
Continue reading...
Continue reading...