Catching errors in componentsKirk Brooks (4/9/14 11:37PM)
Kirk Brooks (4/9/14 11:37 PM)
On Wed, Apr 9, 2014 at 2:41 PM, Keisuke Miyako
color><param>00000,0000,DDEE/param>iit can happen if the component was
compiled, and the host was compiled,
and the component was re-compiled but some methods have changed their
/color>TThat's unlikely in this case. (I never say 'never'...)
or, maybe a .4DIndy file from a previous build was wrongly being used.
(you should remove any old structure index files after every
and make sure that the .4darchive is cleared as well in a client-server
/color>TThese are things I've not been careful about and are very
deal with them and post if anything changes. Good to know about.
color><param>00000,0000,DDEE/param>bbut that will make the code
over-generic, I think.
/color>II agree. Plus you could start to run into the overhead of all
redundant error checking.
color><param>00000,0000,DDEE/param>ccan you confirm whether you call
the component method using a direct
method call (the method is tokenized in the host source code) or
METHOD, EXECUTE METHOD IN SUBFORM, EXECUTE FORMULA, etc?
/color>IIn this case it's a direct call. The example I posted is, in
sample method just to test the situation. The original method was
and more complex but the behavior was the same. It's not compiled.
I take your point about the purpose of error handling though I think we
could debate the scope of what an 'error' is. But in this case the
4D handles essentially the same error differently. More importantly by
allowing me to ignore them.
In this case I was deploying some code that runs on the server (and it
compiled). I assumed any errors would be ignored and they weren't
to the process being stuck on the server with the error message on the
screen. Not a life or death issue this time but it's inconsistent
and that leads to confusion and lost time trying to figure out why.
San Francisco, CA
Reply to this message
Summary created 4/10/14 at 3:30AM by Intellex Corporation
Comments welcome at: email@example.com