Hi Forum, (OE 11.6.2 with StateFree Appserver)
Catching an Progress.Lang.Error works fine for a simple RUN on AppServer (synchronous). I mean -undothrow 2 does the job fine when an unhandled error condition occurs.
On the other hand, I can't find a way to catch an error object when working in asynchronous fashion.
At best, in my async response procedure I can see an error occured on the AppServer side based on SELF:ERROR and ERROR-STATUS:ERROR that are set, but without any detail as ERROR-STATUS:NUM-MESSAGE remains set to 0 and ERROR-STATUS:GET-MESSAGE(1) remains empty.
Did I miss something? Is that a known limitation?
The impact is rather bad as error messages no longer end up in the AppServer log if we use -undothrow 2 or the BLOCK-LEVEL ON ERROR UNDO, THROW directive in the code.
Thanks
/S
<doc says (asaps.pdf page 124):>
Obtaining error information
With an asynchronous remote procedure request, the RUN...ASYNCHRONOUS statement returns
once the client request has been validated. Any errors that occur while processing the
RUN...ASYNCHRONOUS statement are returned as a STOP or ERROR condition in the context of
the RUN...ASYNCHRONOUS statement. Information on errors that occur once the asynchronous
request has been submitted can be obtained by using the ERROR-STATUS system handle within
the event procedure for the asynchronous request.
If the asynchronous request completes with a condition, you can use attributes on the asynchronous
request handle to determine the condition that the request completed with. For example:
• ERROR attribute indicates if the request completed with an ERROR condition
• STOP attribute indicates if the request completed with a STOP condition
• QUIT attribute indicates if the request completed with a QUIT condition
Note that any asynchronous request that raises the STOP condition (by executing the STOP
statement), and does not handle the condition itself, also sets the STOP attribute of its corresponding
asynchronous request handle to TRUE.
</doc says (asaps.pdf page 124):>
That is currently a limitation. We are looking at making that error object available from the event procedure but that would be for a future release.
That is currently a limitation. We are looking at making that error object available from the event procedure but that would be for a future release.
Thank you for your reply Fernando. There will be concerns for people that already use structured error handling and that educate existing AppSever invocations to go asynchronous, because at present the thrown error object gets lost (and nothing will appear in the AppServer log file). For now, the way I found to catch error details is to add a Progress.Lang.Error object extra output param (or as a property or in an extra serializable response object output param), prepared in a main catch of the called .p procedure.
This topic is somehow connected to the unhandled exception idea we were mentioning with Laura this year. It would be nice to bring all that together (ability to catch details about stop conditions as well)
Bizarre, I cannot find out how to mark this thread as Answered
Your thread was not marked as a question to begin with.
Agree with Sebastian that those points should be taken care of (including the STOP cause, being able to detect STOP-AFTER).
Still time for 11.7, I hope!
No disagreement here. The asynchronous request issue is something we are hoping to address sooner than later. As far as handling of STOP, etc, that's something we are still analyzing.
Who is the question marker? ;)
The initial poster ;-)
(on a side note, you think France will be able to beat those Iceland players?)
OK found it... missed it in the UI at the very beginning. One needs to Edit his original post to mark it as a question.
Would be fun to see Iceland making it , or to be juste "before last" just to annoy the English et bit more ;)