Unhandled runtime errors kill form timer events

[mat]

Does anyone have a decent way to deal with unhandled errors, which kill
globla vars and stop form timer events from taking place? I use unbound
forms (and temp tables) to keep alive some data points for reference, so
the global vars part is not so much of a problem. But I'm having a hard
time coming up with a good way to deal with form timer events which stop
firing if there is an unhandled exception.

 

[Marshall Barton]

Does anyone have a decent way to deal with unhandled errors, which kill
globla vars and stop form timer events from taking place? I use unbound
forms (and temp tables) to keep alive some data points for reference, so
the global vars part is not so much of a problem. But I'm having a hard
time coming up with a good way to deal with form timer events which stop
firing if there is an unhandled exception.

Seems like you really need to either prevent all errors
(impossible) or hanfle all errors (tedious but easy).

 

[Marshall Barton]

Whoops.

It's either that or don't use timer event.

If you really, really must have timer events (generally not
a good idea), then you should try to prevent as many common
errors as feasible and handle **all** errors.

Note, as David Fenton so clearly pointed out recently, the
bare minimum error handling is to handle all errors in every
top level procedure which will at least trap errors in any
lower level procedures. IMO, you should still use code to
prevent any anticipated errors.

 

[mat]

Whoops.

It's either that or don't use timer event.

If you really, really must have timer events (generally not
a good idea), then you should try to prevent as many common
errors as feasible and handle **all** errors.

Note, as David Fenton so clearly pointed out recently, the
bare minimum error handling is to handle all errors in every
top level procedure which will at least trap errors in any
lower level procedures. IMO, you should still use code to
prevent any anticipated errors.

I will have to error trap as best I am able.

What would you recommend instead for form timer events? I've got several
complex apps that rely on timer events to peridocally refresh lists and
so forth.

 

[Albert D. Kallal]

Just deploy your application as a mde, and un-handled errors will not reset
local and global vars...

 

[John W. Vinson]

Just deploy your application as a mde, and un-handled errors will not reset
local and global vars...

Won't they simply exit the database though?

 

[Marshall Barton]

I will have to error trap as best I am able.

What would you recommend instead for form timer events? I've got several
complex apps that rely on timer events to peridocally refresh lists and
so forth.

That may be a good reason for using timer events, but some
kind of semaphore coordination could also do the job. It
would be noce if you could raise a "data updated" event in
another app, but they would all need to be programmed for
that.

Since a timer seems like your best choice, you really need
to add error handling just about everywhere. There are
tools available that will do it semi automatically. This
one is frequently recommended:
http://www.mztools.com/v3/mztools3.aspx

 

[mat]

Won't they simply exit the database though?

Yes as far as I know.

 

[Albert D. Kallal]

Won't they simply exit the database though?
--

No, the runtime ONLY exits after an error if you deploy mdb.

Deplying a mde NEVER resets global or local vars, and it NEVER quits the
runtime due to an error....

This runtime "exit due to error" only ever occurred if you deployed a mdb.

A mde does not re-set vars on a un-handled error, and it also don't exit the
runtime when that errors occurs.

This is likely the #1 reason why I always deployed mde's with the
runtime...it don't quit when there is an error....

 

[Albert D. Kallal]

Yes as far as I know.

no, the runtime ONLY exits if you deploy a mdb, with an mde..un-handle
errors DOES NOT exit....it just keeps on running (with all local and global
vars intact).

 

[mat]

no, the runtime ONLY exits if you deploy a mdb, with an mde..un-handle
errors DOES NOT exit....it just keeps on running (with all local and global
vars intact).

That's a great thing to learn, completely unexpected.

 

[John W. Vinson]

No, the runtime ONLY exits after an error if you deploy mdb.

Deplying a mde NEVER resets global or local vars, and it NEVER quits the
runtime due to an error....

This runtime "exit due to error" only ever occurred if you deployed a mdb.

A mde does not re-set vars on a un-handled error, and it also don't exit the
runtime when that errors occurs.

This is likely the #1 reason why I always deployed mde's with the
runtime...it don't quit when there is an error....

Thanks, Albert! I'd overgeneralized the warnings that had been drummed into me
here.

Of course that does mean that if a MDE has an unhandled error it keeps running
even though an error has occurred... which might be trivial but might mean
that something is very badly wrong.

 

[David W. Fenton]

Since a timer seems like your best choice, you really need
to add error handling just about everywhere.

Well, it's also possible to avoid global variables, and replace them
with self-healing data structures. These can be in the form of
something like a class module, that can be written to initialize to
its default values in the class module's initialize event. Or,
instead of using global variables, use functions that have a static
variable that is re-initialized if it's reset.

Of course, these things will work only for values that are looked up
from tables, or set to a known initial value when an app starts up.
Global variables used to pass data collected at runtime between
forms, for instance, won't be replaceable with those kinds of
structures. Well, they can be, and that would allow them to recover
from a code reset, but not necessarily with the appropriate data.

I avoid Globals for the most part. And I don't distribute MDEs. And
I don't error trap everything. And my apps don't fail often, either.

In general, any time you use a Global, you should test to make sure
it's properly initialized. One approach to that is to wrap a
function around it, but if you're going to do that, you might as
well get rid of the Global and use a Static variable inside the
function itself.