Throwing errors from proSIinvokeTaskAsync.p Cancel

1. Simon Prinsloo

   

   11 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

   

   319 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

   

   11 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

   

   319 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

   

   11 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

   

   319 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

   

   11 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.