Re: ON ERR CALL: Comments & Seeking Comments

2017-05-15 Thread Sannyasin Siddhanathaswami via 4D_Tech
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

2017-05-14 Thread David Adams via 4D_Tech
> 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

2017-05-14 Thread Sannyasin Siddhanathaswami via 4D_Tech
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

2017-05-12 Thread David Adams via 4D_Tech
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
**