Private versus public variables and error handling

[Anthony England]

Everyone knows that global variables get re-set in an mdb when an un-handled
error is encountered, but it seems that this also happens when the variable
is defined as private at form-level.

So if "global variables get re-set" doesn't tell the whole story, then what
does?
***please note***
I'm not looking for a solution - I'm looking for a more detailed description
of what happens when an un-handled error occurs - possibly with help file or
website reference.
Example:
Three buttons on a form, press them 1,2,3 (which causes an un-handled error)
then back to 2. m_strCode is re-set.

Private m_strCode As String

Private Sub cmdOne_Click()
m_strCode = "A1"
End Sub

Private Sub cmdTwo_Click()
MsgBox m_strCode
End Sub

Private Sub cmdThree_Click( )
MsgBox CStr(1 / 0)
End Sub

[David W. Fenton]

"Anthony England" <ae******@oops. co.uk> wrote in
news:dl******** **@nwrdmz01.dmz .ncs.ea.ibs-infra.bt.com:

Everyone knows that global variables get re-set in an mdb when an
un-handled error is encountered, but it seems that this also
happens when the variable is defined as private at form-level.

So if "global variables get re-set" doesn't tell the whole story,
then what does?
***please note***
I'm not looking for a solution - I'm looking for a more detailed
description of what happens when an un-handled error occurs -
possibly with help file or website reference.
Example:
Three buttons on a form, press them 1,2,3 (which causes an
un-handled error) then back to 2. m_strCode is re-set.

Private m_strCode As String

Private Sub cmdOne_Click()
m_strCode = "A1"
End Sub

Private Sub cmdTwo_Click()
MsgBox m_strCode
End Sub

Private Sub cmdThree_Click( )
MsgBox CStr(1 / 0)
End Sub

Change the private module-level variable either to a function or a
custom property:

Private Function strCode() As String
Static strCodeStatic As String

If Len(strCodeStat ic) = 0 Then
strCodeStatic = "A1"
End If
strCode = strCodeStatic
End Function

OR:

Private Property Get strCode() As String
Static strCodeStatic As String

If Len(strCodeStat ic) = 0 Then
strCodeStatic = "A1"
End If
strCode = strCodeStatic
End Property

I'm not sure that there's any advantage to one or the other.

The key here is that the value is set to a static variable internal
to your function/property, and if the code has been reset, the
static variable is re-assigned transparently.

The advice I've given about avoiding global variables applies to
module-level variables, too.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Anthony England]

"David W. Fenton" <dX********@bwa y.net.invalid> wrote in message
news:Xn******** *************** ***********@216 .196.97.142...

"Anthony England" <ae******@oops. co.uk> wrote in
news:dl******** **@nwrdmz01.dmz .ncs.ea.ibs-infra.bt.com:

Everyone knows that global variables get re-set in an mdb when an
un-handled error is encountered, but it seems that this also
happens when the variable is defined as private at form-level.

So if "global variables get re-set" doesn't tell the whole story,
then what does?
***please note***
I'm not looking for a solution - I'm looking for a more detailed
description of what happens when an un-handled error occurs -
possibly with help file or website reference.
Example:
Three buttons on a form, press them 1,2,3 (which causes an
un-handled error) then back to 2. m_strCode is re-set.

Private m_strCode As String

Private Sub cmdOne_Click()
m_strCode = "A1"
End Sub

Private Sub cmdTwo_Click()
MsgBox m_strCode
End Sub

Private Sub cmdThree_Click( )
MsgBox CStr(1 / 0)
End Sub

Change the private module-level variable either to a function or a
custom property:

Private Function strCode() As String
Static strCodeStatic As String

If Len(strCodeStat ic) = 0 Then
strCodeStatic = "A1"
End If
strCode = strCodeStatic
End Function

OR:

Private Property Get strCode() As String
Static strCodeStatic As String

If Len(strCodeStat ic) = 0 Then
strCodeStatic = "A1"
End If
strCode = strCodeStatic
End Property

I'm not sure that there's any advantage to one or the other.

The key here is that the value is set to a static variable internal
to your function/property, and if the code has been reset, the
static variable is re-assigned transparently.

The advice I've given about avoiding global variables applies to
module-level variables, too.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Thanks for that, David. As I mentioned, it's not really a workaround I'm
looking for as I do have a stratgegy to avoid this. It's more a question of
trying to concisely state what happens when an un-handled error occurs.
Previously, I would have said "... global variables (those defined as public
in an external module) get re-set". Now I might amend that to "...
variables defined as public in modules plus those defined at form level get
re-set"
However, that's not that concise and may not be the end of the story. Could
there be any other bits that have escaped my attention? Does anyone want to
try to complete the following sentence clearly and concisely:
When an un-handled error occurs....

[Albert D. Kallal]

>

So if "global variables get re-set" doesn't tell the whole story, then
what does?
The whole storey:
A unhandled error will reset variables (end of story). (that is it,
nothing more, nothing less).

It does not matter if the variable is local to a form, global to a module,
private or whatever. In plain English, a un-handled error re-sets variables.
That is it...done, all variables get re-set. There is no "thinking" here,
but things are simply re-set.
***please note***
I'm not looking for a solution -

Actually, there is a simply catch all solution. Just distribute a mde to
your users. All errors now, even when you don't trap them will NOT cause
variables to be re-set. This is one of "many" reasons why you want to use a
mde. I explain a few others in this article of mine:

http://www.members.shaw.ca/AlbertKal...plit/index.htm
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl************* ****@msn.com
http://www.members.shaw.ca/AlbertKallal

[Albert D. Kallal]

> However, that's not that concise and may not be the end of the story.

Could there be any other bits that have escaped my attention? Does anyone
want to try to complete the following sentence clearly and concisely:
When an un-handled error occurs....

all variables get reset.

(that is 4 words, and is the end of the story).

You can see my other post, as I mentioned that using a mde will NOT reset
variables, and is on reason why they are far more reliable for your users.
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl************* ****@msn.com
http://www.members.shaw.ca/AlbertKallal

[lylefair]

Albert D. Kallal wrote:

Actually, there is a simply catch all solution. Just distribute a mde to
your users. All errors now, even when you don't trap them will NOT cause
variables to be re-set. This is one of "many" reasons why you want to use a
mde. I explain a few others in this article of mine:

It is not a reason why I want to use an mde. After an unhandled error I
want to require that the application be closed and, maybe, in some
situations, restarted, .. probably not. [A BSD woouldn't really upset
me]. A note to the developer would be a nice touch because the
unhandled arror shouldn't happen; it should be handled or fixed.

To those who say, "Oh, what an inconvenience!" , I say. "Learn your
trade!"; if you are just dabbling then dabble better.

[david epsom dot com dot au]

> It is not a reason why I want to use an mde. After an unhandled

want to require that the application be closed and, maybe, in some
Runtime does this to .mdb's. Unhandled errors cause the application to
close.

In an MDE, on unhandled errors the Runtime version discards the custom error
message, substitutes it's own error message, and continues.

(david)
"lylefair" <ly***********@ aim.com> wrote in message
news:11******** *************@o 13g2000cwo.goog legroups.com... Albert D. Kallal wrote:

Actually, there is a simply catch all solution. Just distribute a mde to
your users. All errors now, even when you don't trap them will NOT cause
variables to be re-set. This is one of "many" reasons why you want to use
a
mde. I explain a few others in this article of mine:

It is not a reason why I want to use an mde. After an unhandled error I
want to require that the application be closed and, maybe, in some
situations, restarted, .. probably not. [A BSD woouldn't really upset
me]. A note to the developer would be a nice touch because the
unhandled arror shouldn't happen; it should be handled or fixed.

To those who say, "Oh, what an inconvenience!" , I say. "Learn your
trade!"; if you are just dabbling then dabble better.

[Steve Jorgensen]

On Sun, 13 Nov 2005 15:56:43 -0600, "David W. Fenton"
<dX********@bwa y.net.invalid> wrote:

"Anthony England" <ae******@oops. co.uk> wrote in
news:dl******* ***@nwrdmz01.dm z.ncs.ea.ibs-infra.bt.com:

Everyone knows that global variables get re-set in an mdb when an
un-handled error is encountered, but it seems that this also
happens when the variable is defined as private at form-level.

So if "global variables get re-set" doesn't tell the whole story,
then what does?
***please note***
I'm not looking for a solution - I'm looking for a more detailed
description of what happens when an un-handled error occurs -
possibly with help file or website reference.
Example:
Three buttons on a form, press them 1,2,3 (which causes an
un-handled error) then back to 2. m_strCode is re-set.

Private m_strCode As String

Private Sub cmdOne_Click()
m_strCode = "A1"
End Sub

Private Sub cmdTwo_Click()
MsgBox m_strCode
End Sub

Private Sub cmdThree_Click( )
MsgBox CStr(1 / 0)
End Sub
Change the private module-level variable either to a function or a
custom property:

Private Function strCode() As String
Static strCodeStatic As String

If Len(strCodeStat ic) = 0 Then
strCodeStatic = "A1"
End If
strCode = strCodeStatic
End Function

OR:

Private Property Get strCode() As String
Static strCodeStatic As String

If Len(strCodeStat ic) = 0 Then
strCodeStatic = "A1"
End If
strCode = strCodeStatic
End Property

I'm not sure that there's any advantage to one or the other.

The key here is that the value is set to a static variable internal
to your function/property, and if the code has been reset, the
static variable is re-assigned transparently.

I use the same approach. It works very nicely.
The advice I've given about avoiding global variables applies to
module-level variables, too.

But, of course, private module-level variables are preferrable to global
because at least you can tell what procedures could touch the variables.
Also, we should add that module-level variables in class modules are very
appropriate (though not in massive numbers per module).

[Steve Jorgensen]

On Mon, 14 Nov 2005 00:53:19 GMT, "Albert D. Kallal" <ka****@msn.com > wrote:

However, that's not that concise and may not be the end of the story.
Could there be any other bits that have escaped my attention? Does anyone
want to try to complete the following sentence clearly and concisely:
When an un-handled error occurs....

all variables get reset.

(that is 4 words, and is the end of the story).

You can see my other post, as I mentioned that using a mde will NOT reset
variables, and is on reason why they are far more reliable for your users.

But of course, the same cases that reset variables in an MDB exit an MDE
entirely. Basically, avoid all unhandled errors because they'll cause
problems for your users. At least, put error handlers in all event handler
procedures unless they do nothing but call other procedures with error
handlers, and do not resolve expressions ion parameter expressions.

[Rick Brandt]

"Steve Jorgensen" <no****@nospam. nospam> wrote in message
news:5a******** *************** *********@4ax.c om...

On Mon, 14 Nov 2005 00:53:19 GMT, "Albert D. Kallal" <ka****@msn.com > wrote:
But of course, the same cases that reset variables in an MDB exit an MDE
entirely.

I believe you are describing what happens in the runtime, which has nothing to
do with the file being an MDE. Even in the runtime it is not entirely true that
an unhandlled error always causes the app to quit, but that is the most common
result.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com