D
dbeavon
Guest
My recollection is that, where AppError's are concerned, the most natural place to put an error is in the ReturnValue. I think that THROW'ing an AppError with a ReturnValue is equivalent to using the legacy statement : "RETURN ERROR CH-error" (*** docs below ***). This is also the way in which our remote openclients have always received an error message which had been raised within appserver. *** From docs: When the AVM encounters the RETURN ERROR statement, it implicitly throws a Progress.Lang.AppError error object and places any error string in the object's ReturnValue property. Given how natural it is to put something in the AppError ReturnValue, it is odd that the generic "Progress.Lang.Error" interface seems to have no ability to retrieve the "ReturnValue" error message from one of these AppErrors. It would be nice if there was a ToString() abstraction that would get the error details regardless of whether they were stored in ReturnValue or in GetMessage/NumMessages. (Maybe it should give the stack information too, while we're at it). EG. Below is a block of code which proves that no meaningful message can be extracted from an AppError via the "Progress.Lang.Error" interface: BLOCK-LEVEL ON ERROR UNDO, THROW. DEFINE VARIABLE p_Error AS CHARACTER NO-UNDO INIT "Unexpected". /* ************************************************************************ */ /* Do the work, and return failures in p_Error. */ /* ************************************************************************ */ DO ON ERROR UNDO, THROW: RUN MyLogic/ThrowAndCatch/ThrowError.p. CATCH v_ErrorInterface AS Progress.Lang.Error : /* Build message from Progress.Lang.Error */ DEFINE VARIABLE v_LoopMessages AS INTEGER INITIAL 1 NO-UNDO. DEFINE VARIABLE v_ErrorMessages AS CHARACTER INITIAL "" NO-UNDO. DO v_LoopMessages = 1 TO v_ErrorInterface:NumMessages: /* Concatenate them all together */ v_ErrorMessages = v_ErrorMessages + v_ErrorInterface:GetMessage(v_LoopMessages) + " ". END. p_Error = "An error was encountered in {&FILE-NAME}. " + "It has " + STRING(v_ErrorInterface:NumMessages > 0, "message: /no message.") + v_ErrorMessages. /* Done */ RETURN. END CATCH. END. /* DO */ The code in my MyLogic/ThrowAndCatch/ThrowError.p can be RETURN ERROR "RETURNED ERROR". or it can be UNDO, THROW NEW Progress.Lang.AppError("THROWN ERROR"). In both cases, an AppError is raised, and in neither case is the related message going to be accessible via the generic Progress.Lang.Error interface. One thing that is really quite mysterious to me is why the PASOE agent log knows that -debugalert should be used to print the details about certain errors and not others. Does it filter out ALL error classes that are AppError (or derived from AppError) ? Or perhaps it maybe it is able to distinguish between when errors are escaping via RETURN ERROR, rather than UNDO, THROW ? I will try to hunt for a KB. It seems odd that PASOE makes a clear distinction between two types of errors - ones that should or should not be printed to the agent log. However from within ABL itself, there is no distinction between the errors (unless it is somehow based on the class type of the error).
Continue reading...
Continue reading...
