There is no way to recover, but the 4D dialog can capture the exact error and line number and give the user two options, Abort and Continue?
I would be fine with 4D aborting the process and writing the error information to the event log. Showing the dialog on the on the server or web server while the process on the other side of the connection waits forever is not a good solution. Most programming environments have a way to deal with runtime errors. Many good ones have constructs like try/catch/throw. 4D really needs something like this. John DeSoi, Ph.D. > On Mar 3, 2017, at 6:00 PM, Keisuke Miyako via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > I wrote this almost ironically but maybe there is something to it. > > I still hold the view that ON ERROR CALL should not apply to runtime errors, > as there are no logical ways to recover from them, > but would a "feature" that allows the customisation of the runtime error > dialog make sense? > one that includes such options as "send information (e.g. Info Component log) > to the developer", etc. ********************************************************************** 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:4d_tech-unsubscr...@lists.4d.com **********************************************************************
