S
Simon L. Prinsloo
Guest
To answer the original question: ProError is the super class for AppError and SysError, but not for other errors, e.g. .Net errors. But all errors implements the Error interface. So you can catch the AppError and use its ReturnValue and/or any messages it contains, followed by catching the Error interface to catch anything else that is left. Alternatively you can catch the Error interface only. If it has no messages, you can test if it is an AppError and if so, cast it and check for a ReturnValue. I do not quite comprehend why the two AppError contructors cause you to always end up without a message somewhere, as it always complicates things and leads to unnatural code, e.g. "NEW AppError('My messages', any0meaningless-integer)" just to get the "new" structured error handling to work. For compatibility with traditional errors, I would expect that the ReturnValue property's getter should simply map to GetMessage(1) and that it would either be a) ReadOnly, or b) have a setter that either insert the message in the first position or clear all other messages and insert only the supplied message. This would also enabled us to use structured error handling while still using the more productive, simpler to read, easy to type, RETURN ERROR "Some message" to raise the AppError, which would be closer to the life long philosophy of PSC to produce a 4GL where the programmer focus on what, not how, something happens.
Continue reading...
Continue reading...