|
|
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.
|
|
mat wrote:
[Quoted Text] >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).
--
Marsh
MVP [MS Access]
|
|
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.
--
Marsh
MVP [MS Access]
|
|
In article <r83gk49b48gimcilai2a14o4ic596jig0q[ at ]4ax.com>,
marshbarton[ at ]wowway.com says...
[Quoted Text] > 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.
|
|
Just deploy your application as a mde, and un-handled errors will not reset
local and global vars...
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal[ at ]msn.com
|
|
On Tue, 16 Dec 2008 21:50:14 -0700, "Albert D. Kallal"
<PleaseNOOOsPAMmkallal[ at ]msn.com> wrote:
[Quoted Text] >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?
--
John W. Vinson [MVP]
|
|
mat wrote:
[Quoted Text] >In article <r83gk49b48gimcilai2a14o4ic596jig0q[ at ]4ax.com>,
>marshbarton[ at ]wowway.com says...
>> 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.
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
--
Marsh
MVP [MS Access]
|
|
In article <sp1hk498585dke29p3hvus41vll5sdv9vg[ at ]4ax.com>,
jvinson[ at ]STOP_SPAM.WysardOfInfo.com says...
[Quoted Text] > On Tue, 16 Dec 2008 21:50:14 -0700, "Albert D. Kallal" > <PleaseNOOOsPAMmkallal[ at ]msn.com> wrote: > > >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? >
|
|
"John W. Vinson" <jvinson[ at ]STOP_SPAM.WysardOfInfo.com> wrote in message
news:sp1hk498585dke29p3hvus41vll5sdv9vg[ at ]4ax.com...
[Quoted Text] > On Tue, 16 Dec 2008 21:50:14 -0700, "Albert D. Kallal" > <PleaseNOOOsPAMmkallal[ at ]msn.com> wrote: > >>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? > --
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 (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal[ at ]msn.com
|
|
"mat" <mat[ at ]notarealdotcom.adr> wrote in message
news:MPG.23b2397ff10b157b989748[ at ]msnews.microsoft.com...
[Quoted Text] > In article <sp1hk498585dke29p3hvus41vll5sdv9vg[ at ]4ax.com>, > jvinson[ at ]STOP_SPAM.WysardOfInfo.com says... >> On Tue, 16 Dec 2008 21:50:14 -0700, "Albert D. Kallal" >> <PleaseNOOOsPAMmkallal[ at ]msn.com> wrote: >> >> >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? >> > 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).
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal[ at ]msn.com
|
|
In article <OqoQ4bBYJHA.4852[ at ]TK2MSFTNGP04.phx.gbl>,
PleaseNOOOsPAMmkallal[ at ]msn.com says...
[Quoted Text] > "mat" <mat[ at ]notarealdotcom.adr> wrote in message > news:MPG.23b2397ff10b157b989748[ at ]msnews.microsoft.com... > > In article <sp1hk498585dke29p3hvus41vll5sdv9vg[ at ]4ax.com>, > > jvinson[ at ]STOP_SPAM.WysardOfInfo.com says... > >> On Tue, 16 Dec 2008 21:50:14 -0700, "Albert D. Kallal" > >> <PleaseNOOOsPAMmkallal[ at ]msn.com> wrote: > >> > >> >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? > >> > > 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).
That's a great thing to learn, completely unexpected.
|
|
On Wed, 17 Dec 2008 00:12:13 -0700, "Albert D. Kallal"
<PleaseNOOOsPAMmkallal[ at ]msn.com> wrote:
[Quoted Text] >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.
--
John W. Vinson [MVP]
|
|
Marshall Barton <marshbarton[ at ]wowway.com> wrote in
news:av1hk49c78ooa1q2pd0g6i2uubii58dkac[ at ]4ax.com:
[Quoted Text] > 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.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
|