Is there a way to check the state of the error handler?

[JJ]

i.e. the state which is affected by these statements:

On Error Resume Next 'disable error handling
On Error Goto 0 'enable error handling

[Auric__]

Post by JJ
On Error Resume Next 'disable error handling
On Error Goto 0 'enable error handling

What are you trying to accomplish?

I suppose you could do something like this:
Dim errflag As Boolean
On Error GoTo blah
If blah Then
MsgBox "error handler is enabled"
Else
MsgBox "error handler is disabled"
End If
blah:
errflag = True
Resume Next

[JJ]

Post by Auric__

Post by JJ
On Error Resume Next 'disable error handling
On Error Goto 0 'enable error handling

What are you trying to accomplish?
Dim errflag As Boolean
On Error GoTo blah
If blah Then
MsgBox "error handler is enabled"
Else
MsgBox "error handler is disabled"
End If
errflag = True
Resume Next

I have several scripts which are intended to be combined together into a
larger script. Similar like C/C++ header files (if you know), but has
executable code. Call them "include" scripts.

Some code in the "include" scripts need to do its tasks without the error
handler enabled, because the task may throw an exception, and I want to
manually handle the error so that the code may proceed.

Since I need the error handler enabled for other parts of the code (where
they don't have a manual error handler), I'd need to preserve the original
state of the error handler before disabling it, and restore it back to its
original state - whether it was originally enabled or disabled.

Keep in mind that the code within the "include" scripts doesn't aware of
each other. One may use variables as input, and produce another for output,
but they won't know which script will provide the input variables, and which
script will use the output variables.

[Mayayana]

"JJ" <***@vfemail.net> wrote

| i.e. the state which is affected by these statements:
|
| On Error Resume Next 'disable error handling
| On Error Goto 0 'enable error handling

I think you meant those the other way around.
GoTo 0 to disable error handling. But it's an
understandable mistake. The way the help describes
it is confusing, like a multiple negative statement.

The system is "handling" errors all the time. It's just
a matter of whether you want to stop execution on
errors or manage the next step yourself. Allowing
execution to be stopped is also a way of handling the
error.

'-------------------------------

Err.Clear '-- Not necessary, since the script just started.
'Also because an On Error line is supposed to clear
' the error record. Though personally I avoid trusting
'that.

On Error Resume Next
x = 5 \ 0

If Err.Number <> 0 Then
MsgBox Err.Number & vbCrLf & Err.Description
End If
'---------------------------------

Either way, the script shows the error.

But to your question....
How do you arrive at a point where you
don't know how you've left it? I can't see that.
But if you do, it's easy enough to just add the
"On Error" line of your choice.

[JJ]

Post by Mayayana
|
| On Error Resume Next 'disable error handling
| On Error Goto 0 'enable error handling
I think you meant those the other way around.
GoTo 0 to disable error handling. But it's an
understandable mistake. The way the help describes
it is confusing, like a multiple negative statement.
The system is "handling" errors all the time. It's just
a matter of whether you want to stop execution on
errors or manage the next step yourself. Allowing
execution to be stopped is also a way of handling the
error.

Yeah. Maybe I should've mention it as "exception" rather than "error
handling".

Post by Mayayana
How do you arrive at a point where you
don't know how you've left it? I can't see that.
But if you do, it's easy enough to just add the
"On Error" line of your choice.

It's a bit difficult to explain. Please see my reply to Auric message.

Basically it's because it works like a C header files. i.e. each script
doesn't aware of each other, and may not make sense on its own. It'll only
make sense when combined with other scripts.

[Mayayana]

"JJ" <***@vfemail.net> wrote

| It's a bit difficult to explain. Please see my reply to Auric message.
|
| Basically it's because it works like a C header files. i.e. each script
| doesn't aware of each other, and may not make sense on its own. It'll only
| make sense when combined with other scripts.

I find error handling seems to "bubble up". In other words,
an HTA Button1_onclick might have On Error Resume Next.
That then calls another sub or function, which calls a 3rd,
which calls a 4th. It all gets error-trapped. I've never tested
to figure out the details. I guess you could do something like:

Sub DoIt()
On Error GoTo 0
' code in sub
On Error Resume Next
End Sub

According to the docs it doesn't matter when the sub
ends, but if it bubbles up then GoTo 0 might also bubble
up and thus need to be cleared.

I tend to use another approach: If I need to test
something I might comment out all error trapping
until I figure out the problem. Though sometimes
errors are expected, so that can be awkward.
Once the code is pretty much finished, and I've
made it as stable as possible with error trapping, I
just add On Error Resume Next at the top of
everything. My logic is that I've dealt with all
the likely problems. Any problem that then might
arise would be a fluke and it's probably going to
do more harm than good to stop everything for such
a problem.

[R.Wieser]

JJ,

Is there a way to check the state of the error handler?

As far as I know (and the responses seem to indicate), no.

i.e. the state which is affected by these statements: [snip]

But I think there still is a way:
1) either of those commands sets "err.number" to Zero.
2) "err.number" will not be set to anything else by the scripting engine
(unless an error occurs ofcourse).

The solution seems to be to execute "err.number = -1" (or something like it)
at the top of the code, which means that if "err.number" than becomes
anything else either of the two commands you mentioned has been executed
(and maybe a subsequent error is detected).

Would that be usefull ?

Regards,
Rudy Wieser

[JJ]

Post by R.Wieser
1) either of those commands sets "err.number" to Zero.

I didn't know this.

Post by R.Wieser
2) "err.number" will not be set to anything else by the scripting engine
(unless an error occurs ofcourse).
The solution seems to be to execute "err.number = -1" (or something like it)
at the top of the code, which means that if "err.number" than becomes
anything else either of the two commands you mentioned has been executed
(and maybe a subsequent error is detected).
Would that be usefull ?

Certainly. It's pretty solid, too. I could use this.
Thanks.

[R.Wieser]

JJ,

Post by JJ

Post by R.Wieser
1) either of those commands sets "err.number" to Zero.

I didn't know this.

It has a kind of logic for the activator command (starting off with an "all
ok" situation). Not so much for the de-activator though.

I ran into it when I wanted to capture a single-line error and thought I
could just wrap it in a pair of "on error resume next" / "on error goto 0"
commands - and than see which error (if any) occurred. I never seemed to
get any, even though the command didn't perform (like trying to create a
file in a non-existing folder).

Post by JJ

Post by R.Wieser
Would that be usefull ?

Certainly. It's pretty solid, too. I could use this.

Great! Its so stupidly simple (when you know about it) that I wasn't quite
sure it would be...

And to be honest about it, I wasn't even sure if I could actually change
"err.number" until I tried it (would not have raised an eyebrow if it would
have been a read-only property).

Regards,
Rudy Wieser

[Mayayana]

"R.Wieser" <***@not.available> wrote

| And to be honest about it, I wasn't even sure if I could actually change
| "err.number" until I tried it (would not have raised an eyebrow if it
would
| have been a read-only property).
|

If you don't want to trust On Error Resume Next
to clear the error then why not just use Err.Clear?
Then you don't have to rewrite everything to test
for -1, and you don't have to worry that an
unsupported use may, at some point, fail.

[R.Wieser]

Mayayana,

Post by Mayayana
If you don't want to trust On Error Resume Next
to clear the error

Whut? The fact that the above command actually does clear the error value
is something my offered method *depends* on.

However, I would have liked it if the "on error goto 0" *disabeling* of the
error catching wouldn't reset the error object. So an error status could
easily be checked afterwards.

Post by Mayayana
Then you don't have to rewrite everything to test
for -1,

Re-read the subject line please. Initializing the error number to
something else than the default zero value enables the OP to detect if an
error handler/catcher was invoked at some point (which is not exactly what
the OP asked, but seems to be good enough for him).

Post by Mayayana
and you don't have to worry that an unsupported use may, at some point,
fail.

What makes you think its unsupported ? And why/how do you think it
worries me ? It didn't even cross my mind.

The only thing that happened there is that I (re?)learned something: I'm
allowed to change the error value (and possibly the description and other
properties too) to whatever I want. Which could be usefull.

Regards,
Rudy Wieser

[JJ]

Post by R.Wieser
However, I would have liked it if the "on error goto 0" *disabeling* of the
error catching wouldn't reset the error object. So an error status could
easily be checked afterwards.

That rings a bell.

When I use `on error resume next` and after doing something which may cause
an exception, I always save `Err.Number` into a variable, before executing
`on error goto 0` - because after `on error goto 0`, `Err.Number` is
cleared. However, it didn't occur to me to check more into it.

But logically (or systematically), shouldn't `on error goto 0` not clear
`Err.Number`? Considering that `on error resume next` already does it. There
should be no point for `on error goto 0` to clear `Err.Number`, because when
an exception occurs, `Err.Number` would have beeen replaced with a new value
anyway. Or is there?

[Mayayana]

"JJ" <***@vfemail.net> wrote

| There
| should be no point for `on error goto 0` to clear `Err.Number

Then why wouldn't the statement itself cause an
error? The error number is, say, 7. Then you call
On Error GoTo 0. Thus, the call would have to raise
error 7 if it's not cleared.

[R.Wieser]

Mayayana,

Thus, the call would have to raise error 7 if it's not cleared.

Why ? That command just *disables* the error catching. Why should it
even *need* to raise an error when something is in the error object ? That
doesn't sound quite logical I'm afraid.

The way you put it it sounds like someone threw a hack at it, instead of
solving the problem.

Also, is there *any* situation in which the "On Error GoTo 0" actually does
raise an error (related to the contents of the error object) ? If not,
what is your above statement based on ?

Regards,
Rudy Wieser

[Mayayana]

"R.Wieser" <***@not.available> wrote

| Also, is there *any* situation in which the "On Error GoTo 0" actually
does
| raise an error (related to the contents of the error object) ?

It cancels On Error Resume Next, thus restoring default
behavior of stopping execution on errors. It's only relevant
to cancel On Error Resume Next, so it wouldn't raise
an error. It's saying, "From here on, stop execution if
there's an error." Thus, the only logical way for it to
work is to clear the error object.

Why is this topic getting so complicated? Maybe
we're all just bored for lack of real topics to discuss.

I think the way MS describes it confuses things. On
Error GoTo 0 doesn't "disable error handling". It restores
the default behavior of stopping execution on errors.

On Error.... clears any error. Err.Clear clears any
error. It's not a philosophical issue.

Personally I never use On Error GoTo 0. I don't think
stopping execution is ever relevant outside of debugging.
At the very least, the process can do something
like show a message that there was an unknown
error, and maybe take a guess at what it might have
been. By the time code is finished, there should be
virtually no errors that haven't been planned
for. Most possible problems can be anticipated. The
ones that can't are usually obvious. For instance, if
someone unplugs a drive while my script is trying to
read from it then their mistake will be obvious. It's
not an error in the script execution.

[R.Wieser]

Mayayana,

Post by Mayayana
It cancels On Error Resume Next, thus restoring
default behavior of stopping execution on errors.

And thats, im(ns)ho the *only* thing it should do. For the reason I already
mentioned.

Post by Mayayana
It's only relevant to cancel On Error Resume Next, so
it wouldn't raise an error.

I already asked you to explain that stance (in regard to 'raising an error'
I mean).

Post by Mayayana
"From here on, stop execution if there's an error." Thus, the
only logical way for it to work is to clear the error object.

And I explained why its counter-productive (read: *not* logical). I also
explained why (resetting the error object) it isn't even needed.

Also, your "Thus" stinks. You are trying to combine apples and oranges
there (the word itself implies a link between the two, but that linkage is
not evident, nor have you tried to made it clear). While that might do when
you want to drink some fruit juce, it doesn't have the same result when
talking programming I'm afraid.

Post by Mayayana
Why is this topic getting so complicated? Maybe
we're all just bored for lack of real topics to discuss.

I do not think its complicated at all. But I do not see any of the reasons
you think are evident, so I was-and-am asking you to supply some explanation
to them. So I may understand why the clearing of the error object is
neccesary, ore even the best way to go, when disabeling the error catching.

Post by Mayayana
Personally I never use On Error GoTo 0

Than I sincerily hope you are not using "on error resume next" either.

I myself am using both, tightly wrapped around a single command*/** so its
failure can be detected and handled in-program (instead of aborting it).

*with the error handling outside of the "next"-ing - so any errors in the
error-handling will cause a hard error instead of being, for all intends and
purposes, ignored.

**Which is possibly the difference of POV we are experiencing.

Regards,
Rudy Wieser

P.s
If you do not wish to respond to my questions toward something you posted
than please do say so. As in that case we are not conversing, and any more
time spend on it would be wasted.

Mind you, there is a possibility that clearing the error object on
disabeling the error catching actually *is* the best way to go, and I would
not mind *at all* to be made aware of it (yes, I'm weird that way). But
upto now I have not heard you mention any(thing) that you could support with
facts.

[Mayayana]

"R.Wieser" <***@not.available> wrote

| I already asked you to explain that stance (in regard to 'raising an
error'
| I mean).
|

It may surprise you, but I don't care very
much about the whole thing. Code as you
like. And I concede whatever it is we're
debating. Your constant arguing is auto-erotic
nonsense, doing nothing to clarify anything
for anyone.

[R.Wieser]

Mayayana,

Post by Mayayana
It may surprise you, but I don't care very
much about the whole thing.

I figured as much when I saw your first reply to me. I could not even make
sense of it. It was like you and me where looking at two fully different
posts. You really threw your hat at it.

That you did not actually respond to anything I said (stated, asked or
requested) and kept repeating your own stuff just confirmed it.

.. but I'm a bit of a sucker, not wanting to believe that someone would want
to waste somebody elses time like that. So I assumed I just either did not
quite understand you, or I was not clear enough in what I tried to convey.
Hence me keeping trying.

Alas ... You where indeed just shitting me. Bummer.

Regards,
Rudy Wieser

[R.Wieser]

JJ,

Post by JJ
I always save `Err.Number` into a variable, before executing
`on error goto 0` - because after `on error goto 0`, `Err.Number`
is cleared.

Yup, exactly that. A waste of a good variable, don't you think ? (also you
than have just one of the helpful-when-debugging attributes saved. The
error object has a few others.

Post by JJ
But logically (or systematically), shouldn't `on error goto 0` not
clear `Err.Number`?

Thats what I tried to say. :-)

Also, outside of an "catch the error" block the error object seems to be
rather unuseful: The system than catches it and aborts the script, before
you are able to access the error object.

Regards
Rudy Wieser

[Evertjan.]

Post by R.Wieser
JJ,

Post by JJ
I always save `Err.Number` into a variable, before executing
`on error goto 0` - because after `on error goto 0`, `Err.Number`
is cleared.

Yup, exactly that. A waste of a good variable, don't you think ? (also
you than have just one of the helpful-when-debugging attributes saved.
The error object has a few others.

Post by JJ
But logically (or systematically), shouldn't `on error goto 0` not
clear `Err.Number`?

Thats what I tried to say. :-)
Also, outside of an "catch the error" block the error object seems to be
rather unuseful: The system than catches it and aborts the script,
before you are able to access the error object.

Well, you can test any number of statements
after a single 'on error resume next'
and outut or store the Err.Number.

If you do not do an Err.Clear,
the Err.Number will only be overwritten on a new error,
while correct statements would not reset the Err.Number.

on error resume next

q = 8 / 0
ErrNumber1 = Err.Number '' 11

Err.Clear
qwerty
ErrNumber2 = Err.Number '' 13

'''Err.Clear
q = 8 / 1
ErrNumber3 = Err.Number '' 13

Err.Clear
q = 8 / 2
ErrNumber4 = Err.Number '' 0

Here ErrNumber3 would carry the error of the querty statement,
so 'q = 8 / 1' might be construed as being erroneous.

[R.Wieser]

Evertjan,

Post by R.Wieser
Also, outside of an "catch the error" block the error object seems to be
rather unuseful: The system than catches it and aborts the script,
before you are able to access the error object.

Well, you can test any number of statements after a single 'on error
resume
next' and outut or store the Err.Number.

Yep, you could do that. And I'm sure there is a possibility that such a
construct will be used by someone somewere. Though I doubt that the
contents of ErrNumber4 will be of much interest when the contents of
ErrNumber1 have found to be non-zero.

And that "just grab the errors, but chug on regardless" approach is quite
dangerous when using anything else than the most simple of things (like
calculations).

So personaly I would try to skip to the end of the "catch" block (using an
"early death" OR comparision alike mechanism) when encountering the first
error. *Much* safer. :-)


But I have to ask, what part of the quoted message did you reply to ?

Regards,
Rudy Wieser

[Evertjan.]

Post by R.Wieser
But I have to ask, what part of the quoted message did you reply to ?

Sorry, I disagree, there is no obligation.

[R.Wieser]

Evertjan,

Post by Evertjan.
Sorry, I disagree, there is no obligation.

I have *no* idea why you said that.

Regards,
Rudy Wieser

[Evertjan.]

Post by R.Wieser
Evertjan,

Post by Evertjan.
Sorry, I disagree, there is no obligation.

I have *no* idea why you said that.

If you skip the line I was responding on,
such conversation is not very useful, Rudy.

[R.Wieser]

Evertjan,

Post by Evertjan.
If you skip the line I was responding on,
such conversation is not very useful, Rudy.

You mean, this line "But I have to ask, what part of the quoted message did
you reply to ?"

Pray tell, how was/is your "Sorry, I disagree, there is no obligation." a
response to it ?

No, you skipped responding to the question itself as well as answering to
it, but went for the end position instead. A defensive one I might add
(which makes me think you know very well what went wrong).

And "you keep using that word. I don't think it means what you think it
means" (from "the princess bride").

Ref: https://en.oxforddictionaries.com/definition/obligation

No, you are not legally bound to anything. Still, although you are Duch (as
am I) we still converse in English. I wonder why ... Some kind of
obligation perhaps ? And you copy-pasted something from my post into
yours. Another kind of obligation perhaps ? You also put my name ontop
of it ... yadayadayada.

And what you did violates *several* obligations. With the major one being
that you're supposed to keep the conversation in an order which your
conversation partner can follow. Which was what my question was all about:
I did not see how what you quoted had any bearing on what you followed it up
with, and I wondered if I missed something. It turns out I didn't, as
there was nothing to miss ...

But in that case, why did you copy-and-paste some random contents and put it
above your problem description ?

Better yet, why did you pick me as adressee, as *nothing* in the problem you
posted had any bearing on what I said or even might have indicated. Heck,
I've never even reference the "err.clear" command, and pretty-much the only
one I did have an opinion on is not part (directly or indirectly) of your
problem description.

And to make matters worse, the clearing-or-not of the error object by the
disabeling of the error catching command would not change anything to the
problem you described.

So, I think you are now able to understand my confusion about why you wrote
that, as well as why you adressed it to me. Nevertheless, I gave you "the
benefit of the doubt", and responded to it as if I where actually the cause
of it. With only a single line asking for clarification.

... And you thought that going defiant would be the best course of action ?
As far as I can tell you made a mistake bub, nothing more than that. The
world didn't end, and I have no intention to haunt you for it. I just
feel sorry that you feel that you had to respond the way you did.

Live long, and prosper (at least long enough to see the erring of your ways
:-) )

(connection closed)

Regards,
Rudy Wieser

[Evertjan.]

Post by R.Wieser

Post by Evertjan.
If you skip the line I was responding on,
such conversation is not very useful, Rudy.

You mean, this line "But I have to ask, what part of the quoted message
did you reply to ?"
Pray tell,

No, I don't pray, not even when ordered to!

Post by R.Wieser
how was/is your "Sorry, I disagree, there is no obligation."
a response to it ?

You seem not to understand how quoting works.

"I have to ask" is that not a statement of obligation?