I am not sure if an out of range is something you would want trap and catch with ON ERR CALL, there is nothing you could do to recover from it.
ON ERR CALL, in my opinion, is only meaningful in the context of an unreliable player (the user, network, or file system) otherwise, for things like type mismatch, missing parameters, or out of range, you only have yourself to blame and an ASSERT seems more appropriate if the route to that line of code is considerably complex. > 2017/02/05 1:38、Arnaud de Montard <[email protected]> のメール： > > When I execute it in ON ERR CALL context, I expect to trap the 1st error > (more interesting…), but the 4d variable 'Error' value is 54. Using GET LAST > ERROR STACK isn't better, the returned codesArray has only one line with > value 54. 宮古 啓介 セールス・エンジニア 株式会社フォーディー・ジャパン 〒150-0043 東京都渋谷区道玄坂1-10-2 渋谷THビル6F Tel: 03-6427-8441 Fax: 03-6427-8449 [email protected] www.4D.com/JP ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
