Re: ON ERR CALL: Comments & Seeking Comments
Great tip! I’ll check it out for sure. Sannyasin Siddhanathaswami On May 14, 2017, 7:07 PM -1000, wrote: Seriously though, if you want a chance to develop more consistent and coherent code, you can't doo better than to read (or re-read) "Code Complete." (There's a second edition now, for those that don't know.) Best. Coding. Book. Ever. ** 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 **
Re: ON ERR CALL: Comments & Seeking Comments
> For generic/lazy error testing (especially for Web Server items), I’ve been > logging the On Err Calls: > > LOG EVENT(Into 4D debug message;Error method+" Error Number: > "+String(Error)+"; Line:"+String(Error line)) > > This is interesting as it shows in the Console.app on a Mac (in the > system.log). This is easily filtered by entering “4D” in the search while > choosing “system.log” > This is helpful when using 4D Server, as Console.app can be open with a screen > sharing session, while doing testing from a client/browser. Hey, very nice idea. I've never done that on OS X, I should try it out and see how I like it. > PS: Thank you for your detailed emails with discoveries and questions and > opinions. I read them with great care and work to implement as much as I can! Kind of you to say...but http://knowyourmeme.com/photos/1045815-old-man-yells-at-cloud ;-) Seriously though, if you want a chance to develop more consistent and coherent code, you can't doo better than to read (or re-read) "Code Complete." (There's a second edition now, for those that don't know.) Best. Coding. Book. Ever. Enjoy ** 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 **
Re: ON ERR CALL: Comments & Seeking Comments
Thanks for this! Very helpful! I’ve started to use it more and more nowadays. I’m really curious how errors in 4D process tags are handled (especially in v16). I’m having a tough time debugging these tags through the 4D Web Server in v15. More testing needed as I didn’t realize you could use "Error line”. Oops. Hopefully the error line is of the html file. Error formula seems to be v16 only. For generic/lazy error testing (especially for Web Server items), I’ve been logging the On Err Calls: LOG EVENT(Into 4D debug message;Error method+" Error Number: "+String(Error)+"; Line:"+String(Error line)) This is interesting as it shows in the Console.app on a Mac (in the system.log). This is easily filtered by entering “4D” in the search while choosing “system.log” This is helpful when using 4D Server, as Console.app can be open with a screen sharing session, while doing testing from a client/browser. PS: Thank you for your detailed emails with discoveries and questions and opinions. I read them with great care and work to implement as much as I can! Sannyasin Siddhanathaswami On May 12, 2017, 4:12 PM -1000, David Adams via 4D_Tech <4d_tech@lists.4d.com>, wrote: Use it. All of the time. ** 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 **
ON ERR CALL: Comments & Seeking Comments
Use it. All of the time. If you're a long-time 4D devleloper like me, you may have started out not using ON ERR CALL much, if at all. I can't remember why I was scared of it, but I tended to avoid it. That all changed forever some versions back for me (6? 6.5?) I think that it's 4D's job to give us errors, but it's our job to catch them. As 4D doesn't have anything else, ON ERR CALL is the tool to use. If you're one of the people that doesn't use it (there must be some), it might help to understand that ON ERR CALL serves a couple of purposes: * Catch errors that are outside of our control and that we can deal with. For example, if you deal with the file system, you may get a file locked error. That's not a bug in our code, it's information about the current state of play in the world. So, ON ERR CALL is functioning as a helpful probe. * Catch errors that shouldn't happen. Like, you know, those darn 4D bugs that we write into our code ;-) Very helpful! Record them, dump details to disk/record and you give yourself a huge head start on solving the problem. If you haven't worked with ON ERR CALL in some time, you'll also be happy to know that there is a lot more information available than there used to be. In the past, there was the Error system variable. Now there's a lot more: Error method The name of the method that caused the error. Error line The line of code that caused the error. Error formula The text of the formula where the error occurred. (Really? When did this show up? I never noticed it before.) Additionally, the GET LAST ERROR STACK provides programmatic access to the error details you may have seen in the new(ish) 4D error dialog. Docs for 16.1: ON ERR CALL http://doc.4d.com/4Dv16/4D/16.1/ON-ERR-CALL.301-3374749.en.html GET LAST ERROR STACK http://doc.4d.com/4Dv16/4D/16.1/GET-LAST-ERROR-STACK.301-3374753.en.html System Variables http://doc.4d.com/4Dv16/4D/16.1/System-Variables.300-3374917.en.html#205035 If you haven't been using ON ERR CALL everywhere, there are some details to sort out. Mainly, what handler applies where on the 4D Server machine. I don't remember them off the top of my head but I do remember that it mattered if you are running compiled or not. I think that triggers share one error handler compiled but need a custom one installed for each trigger in interpreted? Perhaps someone else can post a summary of the current situation. The normal way it works (in almost all cases) is that there is one error handler per process. If there's no custom handler, you fall back on 4D's. If you install a handler, the previous one is cleared. I use a custom stack to track handlers in case I want to install a more specific one and then restore the previous one...but everyone develops there own style. It would be great if some other folks could comment on how they use ON ERR CALL in support of our friends that may not be using it to it's fullest. Anything along these lines is helpful to know: * Gotchas * Details on what to install where * Places that they don't work * What to do with errors * How you handle handlers (like my stack) * Gripes, suggestions, tips ** 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 **