Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > microsoft.public.scripting.vbscript > #11934 > unrolled thread

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

Back to article view | Back to microsoft.public.scripting.vbscript

Contents

  Is there a way to check the state of the error handler? JJ <jj4public@vfemail.net> - 2018-05-15 13:04 +0700
    Re: Is there a way to check the state of the error handler? "Auric__" <not.my.real@email.address> - 2018-05-15 06:55 +0000
      Re: Is there a way to check the state of the error handler? JJ <jj4public@vfemail.net> - 2018-05-15 22:10 +0700
    Re: Is there a way to check the state of the error handler? "Mayayana" <mayayana@invalid.nospam> - 2018-05-15 09:14 -0400
      Re: Is there a way to check the state of the error handler? JJ <jj4public@vfemail.net> - 2018-05-15 22:22 +0700
        Re: Is there a way to check the state of the error handler? "Mayayana" <mayayana@invalid.nospam> - 2018-05-15 11:53 -0400
    Re: Is there a way to check the state of the error handler? "R.Wieser" <address@not.available> - 2018-05-15 17:26 +0200
      Re: Is there a way to check the state of the error handler? JJ <jj4public@vfemail.net> - 2018-05-16 16:52 +0700
        Re: Is there a way to check the state of the error handler? "R.Wieser" <address@not.available> - 2018-05-16 12:42 +0200
          Re: Is there a way to check the state of the error handler? "Mayayana" <mayayana@invalid.nospam> - 2018-05-16 08:34 -0400
            Re: Is there a way to check the state of the error handler? "R.Wieser" <address@not.available> - 2018-05-16 17:36 +0200
              Re: Is there a way to check the state of the error handler? JJ <jj4public@vfemail.net> - 2018-05-19 00:03 +0700
                Re: Is there a way to check the state of the error handler? "Mayayana" <mayayana@invalid.nospam> - 2018-05-18 13:18 -0400
                  Re: Is there a way to check the state of the error handler? "R.Wieser" <address@not.available> - 2018-05-18 20:15 +0200
                    Re: Is there a way to check the state of the error handler? "Mayayana" <mayayana@invalid.nospam> - 2018-05-18 15:12 -0400
                      Re: Is there a way to check the state of the error handler? "R.Wieser" <address@not.available> - 2018-05-19 11:23 +0200
                        Re: Is there a way to check the state of the error handler? "Mayayana" <mayayana@invalid.nospam> - 2018-05-19 10:28 -0400
                          Re: Is there a way to check the state of the error handler? "R.Wieser" <address@not.available> - 2018-05-19 22:19 +0200
                Re: Is there a way to check the state of the error handler? "R.Wieser" <address@not.available> - 2018-05-18 20:06 +0200
                  Re: Is there a way to check the state of the error handler? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-05-18 23:27 +0200
                    Re: Is there a way to check the state of the error handler? "R.Wieser" <address@not.available> - 2018-05-19 12:15 +0200
                      Re: Is there a way to check the state of the error handler? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-05-19 21:30 +0200
                        Re: Is there a way to check the state of the error handler? "R.Wieser" <address@not.available> - 2018-05-19 22:21 +0200
                          Re: Is there a way to check the state of the error handler? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-05-19 22:32 +0200
                            Re: Is there a way to check the state of the error handler? "R.Wieser" <address@not.available> - 2018-05-20 11:06 +0200
                              Re: Is there a way to check the state of the error handler? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-05-20 12:09 +0200

Page 1 of 2  [1] 2  Next page →

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

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

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

[toc] | [next] | [standalone]

#11935

JJ 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

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

-- 
What is evil? Evil is when good gets completely screwed up! Evil is when
brave people can't be brave anymore! Evil is an anagram of vile! There's
got to be a moral standard somewhere!

[toc] | [prev] | [next] | [standalone]

#11937

On Tue, 15 May 2018 06:55:56 -0000 (UTC), Auric__ wrote:

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

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.

[toc] | [prev] | [next] | [standalone]

#11936

"JJ" <jj4public@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.

[toc] | [prev] | [next] | [standalone]

#11938

On Tue, 15 May 2018 09:14:35 -0400, Mayayana wrote:
> "JJ" <jj4public@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.

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

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

[toc] | [prev] | [next] | [standalone]

#11940

"JJ" <jj4public@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. 

[toc] | [prev] | [next] | [standalone]

#11939

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

[toc] | [prev] | [next] | [standalone]

#11941

On Tue, 15 May 2018 17:26:51 +0200, R.Wieser wrote:
> 
> But I think there still is a way:
> 1) either of those commands sets "err.number" to Zero.

I didn't know this.

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

[toc] | [prev] | [next] | [standalone]

#11942

JJ,

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

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

[toc] | [prev] | [next] | [standalone]

#11943

"R.Wieser" <address@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. 

[toc] | [prev] | [next] | [standalone]

#11944

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.

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

> 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

[toc] | [prev] | [next] | [standalone]

#11945

On Wed, 16 May 2018 17:36:42 +0200, R.Wieser wrote:
> 
> 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?

[toc] | [prev] | [next] | [standalone]

#11946

"JJ" <jj4public@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.

[toc] | [prev] | [next] | [standalone]

#11948

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 

[toc] | [prev] | [next] | [standalone]

#11949

"R.Wieser" <address@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. 

[toc] | [prev] | [next] | [standalone]

#11953

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.

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

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

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

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

[toc] | [prev] | [next] | [standalone]

#11956

"R.Wieser" <address@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.

[toc] | [prev] | [next] | [standalone]

#11959

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

[toc] | [prev] | [next] | [standalone]

#11947

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.

> 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 

[toc] | [prev] | [next] | [standalone]

#11950

"R.Wieser" <address@not.available> wrote on 18 May 2018 in
microsoft.public.scripting.vbscript: 

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








-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | microsoft.public.scripting.vbscript

csiph-web