H
Henri Christian Koster
Guest
While we are talking about ERROR-STATUS and its behavior, I would like to request an enhancement - in an attempt to bridge the gap between the old style error handling and THROW / CATCH. Consider in this example that we have an error that was thrown by some new code in the system, but you need to intercept and react on it, but then re-throw the current error. This is not possible, because once you use NO-ERROR, the error object is lost to you. Consider the sample code, after the error was thrown, of what we would like to achieve: RUN someInternalProc NO-ERROR. IF ERROR-STATUS:ERROR THEN DO: someSystemPersistentObject:cleanOutProperties(). IF VALID-OBJECT(ERROR-STATUS:ERROR-OBJECT) THEN RETURN ERROR ERROR-STATUS:ERROR-OBJECT. ELSE RETURN ERROR RETURN-VALUE. END. Out of past experience, I know that I should preserve the error-object / return-value as these could be influenced by code in cleanOutProperties(), but hopefully, having the error-object, I could preserve it. The reason it is important to be able to have access to the error-object is to be able to get at the :CallStack property. Even if I cannot preserve the error-object, I could get the CallStack and re-throw a new error object, where I embed the stack (or part thereof), like what was done with the Dynamics error include.
Continue reading...
Continue reading...