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(strCodeStatic) = 0 Then
strCodeStatic = "A1"
End If
strCode = strCodeStatic
End Function

OR:

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

If Len(strCodeStatic) = 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********@bway.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(strCodeStatic) = 0 Then
strCodeStatic = "A1"
End If
strCode = strCodeStatic
End Function

OR:

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

If Len(strCodeStatic) = 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*********************@o13g2000cwo.googlegro ups.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********@bway.net.invalid> wrote:

"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(strCodeStatic) = 0 Then
strCodeStatic = "A1"
End If
strCode = strCodeStatic
End Function

OR:

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

If Len(strCodeStatic) = 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.com...

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

[Thelma Lubkin]

David W. Fenton <dX********@bway.net.invalid> wrote:
: "Anthony England" <ae******@oops.co.uk> wrote in
:> 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(strCodeStatic) = 0 Then
: strCodeStatic = "A1"
: End If
: strCode = strCodeStatic
: End Function

: OR:

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

: If Len(strCodeStatic) = 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.

Suppose that the code really needs a value not globally known, not
as in this case either a constant "A1" or 0. Let me change
Sub cmdOne_Click slightly:

TRL Private Sub cmdOne_Click()
TRL Static Inum as Integer

TRL Inum = Inum+1
TRL m_strCode = "A" & Format(Inum)
TRL End Sub

Now the function and property that you provide doesn't know the
private variable needed to continue.
Can you please show the workaround for that? I do at times
use global variables that make me uncomfortable

--thelma

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

[Steve Jorgensen]

On Mon, 14 Nov 2005 12:41:37 GMT, "Rick Brandt" <ri*********@hotmail.com>
wrote:

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

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.

Doh! Yes, you're right. I equate the 2 because I'm always using the runtime
to run an MDE.

[David W. Fenton]

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

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....

Everything gets reset. All variables, no matter whether they are
Global or form module-level. If you need the values to survive a
code reset, then you need to use something other than plain
module-level variables (whether public or private).

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

[David W. Fenton]

"Albert D. Kallal" <ka****@msn.com> wrote in
news:3eRdf.498355$1i.55433@pd7tw2no:

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 that doesn't help during develompent, which is the only place it
should really matter.

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

[David W. Fenton]

Thelma Lubkin <th****@alpha2.csd.uwm.edu> wrote in
news:dl**********@uwm.edu:

David W. Fenton <dX********@bway.net.invalid> wrote:
[]
: 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.

Suppose that the code really needs a value not globally
known, not as in this case either a constant "A1" or 0. Let
me change Sub cmdOne_Click slightly:

TRL Private Sub cmdOne_Click()
TRL Static Inum as Integer

TRL Inum = Inum+1
TRL m_strCode = "A" & Format(Inum)
TRL End Sub
Seems silly to have anything like this in the OnClick event of a
command button. It should be a private function or property.
Now the function and property that you provide doesn't know
the private variable needed to continue.
Can you please show the workaround for that? I do at times
use global variables that make me uncomfortable

Well, where does the value come from? A table? An open form?

The re-initialization code should get the value from wherever it is
stored permanently.

If it's not stored permanently, then you have to figure out where
to
get it from, how to recalculate it.

Obviously, there are some kinds of data that can't be recreated in
this way, as they are dependent on the context. But if you have a
code reset, you may be in the same context and maybe can recreate
the data.

But it's often the case that you cannot.

But that kind of code reset should be happening only during the
develompent process, not in production use.

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

[Albert D. Kallal]

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

Fair point. There is often the case where one inherits a application, or
such a time does permit the application to be "correctly" modified.

It is too bad that the world is not perfect...but that just the reality of
this situation.

And, I think there is a number of very trivial routines that don't requite
errors handling in the first place. So, regardless, a mde is simply a more
reliable solution, and this is regardless if you view it as a stop gap until
things can be set right, or you got a situation where you don't believe
that every single routine needs errors handling (I don't).

Further, I worked on a lot of different systems, and what consistently a
error is often a debate. For example, I don't believe that opening a table
that don't exist should case an error. Can you imagine if you try and open a
file in word, and you type in a name that don't exist, and you get execution
error? That is not a error, but the simple fact that the document don't
exist! So, the coding language should give you a nice indication that the
table, file, or whatever does not exist.

In IBM's U2 system (and pick/raining data d3) system for example, opening a
table (or file) does not generate a execution error, but simply gives your
code two paths.

open "tblTest" to fmain else
'
' sorry table does not exist code goes here
end

You can also mix, like

open "tblTfest" to fmain then
' code here for table exists
else
' code here for table not exists
end

You can also see this approach occurring in .net, where you deal with
exceptions, and not a silly runtime error because you just prompted a user
for a file, and it don't exist? (you mean that generates a runtime execution
error?...sheer madness I say!!).

And, I can't tell you the number of times that I got a routine that where
you simply just use on error resume next, and be done with it....

At the end of the day, the real problem is that error handling in VBA is not
elegant, and not nearly as nice in other systems I used. However, we got
what we got, and thus have to live within its means.

So, I not trying to say you don't need error handling. However, I am saying
a lot of small routines I write do NOT need error handling..

Another perfect example of this is when you try and grab a member of custom
collection, and again the above then/else/endif code block should have been
how this was designed, and not a error for these custom collections.

I don't think anyone is disagreeing here that ones needs a good qualify
strategy for error handling, but seen better approachs then what you got
with VBA.

I also don't believe that every routine needs specific error handling beyond
somthing like a on error resume next either....

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

[David W. Fenton]

"Albert D. Kallal" <ka****@msn.com> wrote in
news:sP9ef.499275$oW2.374354@pd7tw1no:

And, I can't tell you the number of times that I got a routine
that where you simply just use on error resume next, and be done
with it....

On Error Resume Next is an abomination that introduces terrible
unreliability, as its scope is not controllable. You may *think*
you're controlling it, but you're probably not.

I never use it any more, at all. If I know an error can be produced
and I can't avoid the error before it has a chance to happen (e.g.,
DoCmd.OpenReport with a NoData event handler that closes the
report), I handle it.

Never, ever, use On Error Resume Next.

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

[david epsom dot com dot au]

A2K occasionally crashes on exceptions - even
exceptions hidden by On Error Resume Next.

So I don't regard On Error Resume Next as
a solution even for routines which do not
require formal try/catch/throw blocks.

(david)
"Albert D. Kallal" <ka****@msn.com> wrote in message
news:sP9ef.499275$oW2.374354@pd7tw1no...

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

Fair point. There is often the case where one inherits a application, or
such a time does permit the application to be "correctly" modified.

It is too bad that the world is not perfect...but that just the reality of
this situation.

And, I think there is a number of very trivial routines that don't requite
errors handling in the first place. So, regardless, a mde is simply a more
reliable solution, and this is regardless if you view it as a stop gap
until things can be set right, or you got a situation where you don't
believe that every single routine needs errors handling (I don't).

Further, I worked on a lot of different systems, and what consistently a
error is often a debate. For example, I don't believe that opening a table
that don't exist should case an error. Can you imagine if you try and open
a file in word, and you type in a name that don't exist, and you get
execution error? That is not a error, but the simple fact that the
document don't exist! So, the coding language should give you a nice
indication that the table, file, or whatever does not exist.

In IBM's U2 system (and pick/raining data d3) system for example, opening
a table (or file) does not generate a execution error, but simply gives
your code two paths.

open "tblTest" to fmain else
'
' sorry table does not exist code goes here
end

You can also mix, like

open "tblTfest" to fmain then
' code here for table exists
else
' code here for table not exists
end

You can also see this approach occurring in .net, where you deal with
exceptions, and not a silly runtime error because you just prompted a user
for a file, and it don't exist? (you mean that generates a runtime
execution error?...sheer madness I say!!).

And, I can't tell you the number of times that I got a routine that where
you simply just use on error resume next, and be done with it....

At the end of the day, the real problem is that error handling in VBA is
not elegant, and not nearly as nice in other systems I used. However, we
got what we got, and thus have to live within its means.

So, I not trying to say you don't need error handling. However, I am
saying a lot of small routines I write do NOT need error handling..

Another perfect example of this is when you try and grab a member of
custom collection, and again the above then/else/endif code block should
have been how this was designed, and not a error for these custom
collections.

I don't think anyone is disagreeing here that ones needs a good qualify
strategy for error handling, but seen better approachs then what you got
with VBA.

I also don't believe that every routine needs specific error handling
beyond somthing like a on error resume next either....

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

[Albert D. Kallal]

"david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
news:43**********************@lon-reader.news.telstra.net...

A2K occasionally crashes on exceptions - even
exceptions hidden by On Error Resume Next.

So I don't regard On Error Resume Next as
a solution even for routines which do not
require formal try/catch/throw blocks.

That is interesting, and I never had the above problem. I not try to suggest
that the lack of a catch block is a excuse to NOT use error handling. I am
not trying to hint that all (that was/is not my point). . However, I am most
certainly saying that some of these small routines don't need error
handling, and some that do are just fine with the on-error resume next. And,
I never seen any difference in stability

As I mentioned, a good example is

on error resume next
docmd.openReprot .
The above two lines is quite common in my code, and never had a problem
(this does assume a two line code routine). I have not seen any difference
in stability, and there is little, if any benefit to putting error code in
the above. Either you spec your application design that will trap a "non"
existing printer (no printer installed), or this is not part of your spec.
If you are NOT spending the extra development dollars to trap "no printer"
installed, or other specify errors, then I see little wrong with the above
two line routine.

Obviously, some see the cost/trade time here differently then I do, and I
have no problem with that. In fact, I assume most of use using something
like the free mztools ad-in, and it will write the error code for you.
(however, even then, I don't necessary use this feature of mztools).

I just don't think the above needs a error handling routine to catch a on-no
data event from the report. I see the on error resume next as sufficient
here. I will MOST certainly say that if you got additional code, then you
better turn of the "resume next". (zero debate on this issue!!).

If your mileage varies on this one..then so be it...
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

[David W. Fenton]

"Albert D. Kallal" <ka****@msn.com> wrote in
news:Qzvef.508556$oW2.107542@pd7tw1no:

I am most
certainly saying that some of these small routines don't need
error handling, and some that do are just fine with the on-error
resume next. And, I never seen any difference in stability

As I mentioned, a good example is

on error resume next
docmd.openReprot .
The above two lines is quite common in my code, and never had a
problem (this does assume a two line code routine).

I agree that not every subroutine needs an error handler.

However, On Error Resume Next is not a way of avoidimg an error
handler. The reason is that it does not go out of scope as you
assume. You'd think that:

Public Sub PrintReport()
On Error Resume Next
DoCmd.OpenReport ...
On Error GoTo 0
End Sub

would be perfectly safe.

But it's not.

That's the only place I have ever used On Error Resume Next, and in
one of my major apps, it was discovered that this was causing
errors
that should have bubbled up to the top from an unsuccessful SAVE of
a record to not come up. Data was lost. And it was a huge pain in
the ass to figure this out (ibookmark navigation without forced
saves before setting the bookmark was also involved, but not the
traditional bookmark bug, because the forms did not allow deletes).

This was back in A97, but what it taught me was not to assume that
On Error GoTo 0 would undo On Error Resume Next, nor that going out
of scope would reset it back to normal.

I recognize that this is not the way things are supposed to be, but
having spent a lot of time troubleshooting the issue, I vowed never
to use it again. That means that where you know you are potentially
encountering an error, you have to handle it.

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

[David W. Fenton]

"Albert D. Kallal" <ka****@msn.com> wrote in
news:Qzvef.508556$oW2.107542@pd7tw1no:

I just don't think the above needs a error handling routine to
catch a on-no data event from the report. I see the on error
resume next as sufficient here. I will MOST certainly say that
if you got additional code, then you better turn of the "resume
next". (zero debate on this issue!!).

It's very easy to write a wrapper routine for opening reports so you
really only need to write an error handler for reports one time.

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

[Bri]

David W. Fenton wrote:

"Albert D. Kallal" <ka****@msn.com> wrote in
news:sP9ef.499275$oW2.374354@pd7tw1no:

And, I can't tell you the number of times that I got a routine
that where you simply just use on error resume next, and be done
with it....

On Error Resume Next is an abomination that introduces terrible
unreliability, as its scope is not controllable. You may *think*
you're controlling it, but you're probably not.

I never use it any more, at all. If I know an error can be produced
and I can't avoid the error before it has a chance to happen (e.g.,
DoCmd.OpenReport with a NoData event handler that closes the
report), I handle it.

Never, ever, use On Error Resume Next.

I would say that there is an exception to this. On Error Resume Next can
be used to deal with an error when where it occurs is important. eg.

On Error Resume Next
do something
If Err.Number<>0 Then Handle Error
do something else
If Err.Number<>0 Then Handle Error

I agree that On Error Resume Next without code to check Err.Number is a
bad idea.

--
Bri