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:[email protected]
**********************************************************************

Reply via email to