Forums / SmartComponent Library - Developer Forum / Throwing errors from proSIinvokeTaskAsync.p

Throwing errors from proSIinvokeTaskAsync.p

7 posts, 0 answered
  1. Simon Prinsloo
    Simon Prinsloo avatar
    9 posts
    Registered:
    20 Feb 2019
    25 Nov 2020
    Link to this post
    Good day

    I noticed that the code to catch and throw an error in proSIinvokeTaskAsync.p is commented out and replaced with code that catch the error and log it, without propagating it.

    I am curious as to why that is and if it relates to any issues regarding throwing errors back on an asynchronous call?

    Regards
    Simon
  2. Mike Fechner
    Mike Fechner avatar
    263 posts
    Registered:
    14 Sep 2016
    26 Nov 2020 in reply to Simon Prinsloo
    Link to this post
    Is this question academic? Or do you have a real world issue? 

    The error handling mechanism in proSIinvokeTaskAsync.p has been like this since the first version. 

    If you have a real issue with this, please create JIRA ticket and we'll try to investigate the reason for the difference here. 
  3. Simon Prinsloo
    Simon Prinsloo avatar
    9 posts
    Registered:
    20 Feb 2019
    27 Nov 2020 in reply to Mike Fechner
    Link to this post
    The question is academic, or maybe more curiosity, as it deviates from the way the rest of the interface works.

  4. Mike Fechner
    Mike Fechner avatar
    263 posts
    Registered:
    14 Sep 2016
    27 Nov 2020 in reply to Simon Prinsloo
    Link to this post
    OK - I'll take a note for myself to investigate this.

    Error handling of async requests is different anyway. The "invoke" usually does not raise the runtime error. That's expected in the async response. So it would have to be handled in an event handler, not in a CATCH block of the invoking routine. 
  5. Simon Prinsloo
    Simon Prinsloo avatar
    9 posts
    Registered:
    20 Feb 2019
    27 Nov 2020 in reply to Mike Fechner
    Link to this post
    The difference in the handling is on the caller's (ServiceAdapter) side.

    proSIinvokeTaskAsync.p is the entry point on the AppServer, thus it can catch the error and/or throw an error, which will have the effect of setting the ERROR and ERROR-OBJECT attributes on the Asynchronous request object handle (SELF in the response procedure) in the caller's session.

    Personally I see no purpose in having proSIinvokeTaskAsync.p, as proSIinvokeTask.p would work just as well for asynchronous calls too, as long as the response procedure defines corresponding INUT parameters of every OUTPUT or INPUT-OUTPUT parameter defined by proSIinvokeTask.p.
  6. Mike Fechner
    Mike Fechner avatar
    263 posts
    Registered:
    14 Sep 2016
    27 Nov 2020 in reply to Simon Prinsloo
    Link to this post
    Yes, maybe that can be changed now. As async calls do support ProDatasets natively now. I believe that was introduced in 11.7 and we do no longer formally support 11.6

    But as long as it does not cause real world functional limitations, the priority is relatively low. 
  7. Simon Prinsloo
    Simon Prinsloo avatar
    9 posts
    Registered:
    20 Feb 2019
    27 Nov 2020 in reply to Mike Fechner
    Link to this post
    Ah yes, indeed. I totally forgot about the lack of native support for ProDatasets. It makes a lot more sense now.
7 posts, 0 answered