WAD ON ERROR GOTO ...

May 20, 2008
10,618
81
Syracuse, NY, USA
See below. Depending on which "on error" statement I use, I get different results. When I use "(echo ERROR! & quit)" I see the error message. If I use "goto badip" I don't see the error message. Am I missing something?
Code:
v:\ip\test> type onerror.btm

iff "%1" EQC "foo" then
  on error (echo ERROR! & quit)
else
  on error goto badip
endiff

set ip=%@lower[%1]

do i=0 to 3
  set octet%i=%@eval[%@word[".",%i,%ip]]
enddo
echo All is OK!
quit

:badip
echo ERROR!
quit


v:\ip\test> onerror.btm foo
ERROR!

v:\ip\test> onerror.btm FOO

v:\ip\test>
 
Last edited:
It seems to work fine on my machine( TCC/LE 14) Try to turn Echo on to see what is happeing. Check your aliass.

c:\>onerror.btm foo
iff "%1" EQC "foo" then
on error (echo ERROR! & quit)
set ip=foo
do i=0 to 3
set octet0=0
(echo ERROR! & quit)
ERROR!

c:\>onerror.btm FOO
iff "%1" EQC "foo" then
on error goto badip
set ip=foo
do i=0 to 3
set octet0=0
goto badip
echo ERROR!
ERROR!
quit
 
May 20, 2008
10,618
81
Syracuse, NY, USA
It has something to do with the error occurring in a DO loop. Here's a better example.
Code:
v:\ip\test> type onerror.btm
iff "%1" EQ "1" then
  on error (echo ERROR! & quit)
else
  on error goto oops
endiff

do i=1 to 2
  BARF
enddo

echo All is OK!
quit

:oops
echo ERROR!
quit


v:\ip\test> onerror.btm 1
ERROR!

v:\ip\test> onerror.btm 0

v:\ip\test>
 
May 20, 2008
10,618
81
Syracuse, NY, USA
Here's the last example with echo on. When the GOTO us used, the last command that's echoed os "goto oops"; what happens there isn't executed or echoed. By the way, BARF in an unknown command. No aliases look troublesome. These are the names of my aliases:
hexe e d b u @@ctrl-F10 ipblock vc8 vc10 xx f @@ctrl-o @@ctrl-u eh eini sl qt tf af cf lv: dt: ldt: predict get ncon mcon tl @@alt-f4 newbeta estart zz

Code:
v:\ip\test> type onerror.btm
@echo on
iff "%1" EQ "1" then
  on error (echo ERROR! & quit)
else
  on error goto oops
endiff

do i=1 to 2
  BARF
enddo

echo All is OK!
quit

:oops
echo ERROR!
quit


v:\ip\test> onerror.btm 1
iff "%1" EQ "1" then
on error (echo ERROR! & quit)
do i=1 to 2
BARF
(echo ERROR! & quit)
ERROR!

v:\ip\test> onerror.btm 0
iff "%1" EQ "1" then
on error goto oops
do i=1 to 2
BARF
goto oops

v:\ip\test>
 
May 20, 2008
10,618
81
Syracuse, NY, USA
Here, it works correctly on v17 and does not work correctly on v18 (or v19 which I used for all of the above posts).
 
Dec 2, 2008
224
2
Canada
It doesn't work for me either, use "ON ERROR GOSUB oops" and a "return" instead of a "quit" at the end of the oops branch and it seems to work.

Here is something interesting:

I load aliases from a file and in the file is

unknown_cmd=echo What kind of command is "%$"?


When I run

onerror.btm 1

Code:
iff "%1" EQ "1" then
on error (echo ERROR! & quit)
do i=1 to 2
BARF
What kind of command is "BARF"?
BARF
What kind of command is "BARF"?
echo All is OK!
All is OK!
quit
And when running

onerror.btm 0

Code:
iff "%1" EQ "1" then
on error goto oops
do i=1 to 2
BARF
What kind of command is "BARF"?
BARF
What kind of command is "BARF"?
echo All is OK!
All is OK!
quit

Using an alias for "unknown_cmd" remove unknown commands from being an errors.
 
May 20, 2008
10,618
81
Syracuse, NY, USA
First, randomly calling an asynchronous GOTO when you're inside a DO loop is a truly awful idea.

Second, it will work if you use the GOTO /I switch. (This is necessary so that the DO loop can clean itself up.)
I read about "/L" but it didn't seem appropriate. It "prevents GOTO from canceling IFF statements and DO loops". I'd think that would prevent the DO loop from cleaning itself up.

Anyway, I found that GOSUB works (no DO-cleanup, but it works) and has the advantage of being able to pass a message at the subroutine's argument
 

rconn

Administrator
Staff member
May 14, 2008
11,925
133
I read about "/L" but it didn't seem appropriate. It "prevents GOTO from canceling IFF statements and DO loops". I'd think that would prevent the DO loop from cleaning itself up.
It would, if you were in the DO loop at the time you're doing the GOTO. But you're not -- the GOTO in the ON ERROR is happening completely independently of the DO loop, which is what causes the problem.
 
May 20, 2008
10,618
81
Syracuse, NY, USA
It would, if you were in the DO loop at the time you're doing the GOTO. But you're not -- the GOTO in the ON ERROR is happening completely independently of the DO loop, which is what causes the problem.
Regardless of the DO loop, I'd expect "on error goto label" to do exactly that on an error, namely, goto the label and execute the commands that follow. If it isn't going to work, it should be documented. The help for "ON" mentions GOTO a few times. I don't think there are any caveats about this situation anywhere in the help.